An ITIL Managing Professional Lens for the Projects I Actually Run

The most useful change in my project-management thinking has been moving from “How do I deliver this?” to “What has to be true for this to keep working after delivery?”

That question matters when the work crosses code, cloud infrastructure, support, privacy, and human routines. It matters even on a small project. A checklist can be beautifully implemented and still fail as a service if a family cannot use it at the point of need, staff do not know how a template is maintained, an error has no next action, or the project quietly promises more than it has validated.

I am studying ITIL’s Managing Professional (MP) material because it gives a practical way to hold those concerns together. I am not presenting VEAI LAB as a formally ITIL-operated organisation. I am using the four modules as an operating-model lens on the projects I actually run.

A project is not finished when the repository is tidy

CareReady makes the distinction concrete. Its core is a care-transfer checklist: a family can work in a browser without creating an account, a facility can publish a template through a share code, the checklist persists locally for offline use, and a separate staff route has authenticated template management.

The repository can demonstrate the technical parts: a PWA, an API, DynamoDB design, Cognito-based access, tests, CI/CD, and a status table. But a working service needs more than those pieces:

• a facility needs to understand how and when to create or update a template;
• a family needs to know what the share code means and what happens if it fails;
• the team needs a way to explain what is in development versus ready to rely on;
• a release needs ownership, support expectations, and a correction path.

That is the gap the ITIL MP view helps me see. It treats a project as a temporary change to a continuing service system.

Direct, Plan and Improve: make the decisions and limits visible

Direct, Plan and Improve (DPI) is the closest MP module to traditional project management: direction, planning, governance, risk, measurement, organisational change, and continual improvement.

In a small studio, governance does not need to mean a committee. It means making the consequential decisions findable. Why is the family path login-free? Why is staff access authenticated? Why are some product pages still marked in development? What is checked before a cloud change is released? Where is the follow-up when a test or deployment assumption turns out to be stale?

I keep those answers in the delivery trail: issue acceptance criteria, repository documentation, architecture notes, CI configuration, and short lessons from failures. On ParkinSync, for example, correcting tests that no longer described the real Lambda handler and aligning the deployment package with the configured handler were not just code fixes. They were governance repairs: the evidence, the release process, and the live implementation needed to say the same thing.

DPI’s practical lesson is that a team should control the decisions that create material risk — without creating enough approval layers that people work around them.

Drive Stakeholder Value: requirements are not the whole relationship

Drive Stakeholder Value (DSV) asks us to look at service relationships, customer journeys, expectations, feedback, and value co-creation. It is particularly useful in care-adjacent product work, where the person using a tool, the person supporting it, and the person deciding whether it is safe to introduce may be different people.

For CareReady, a family may care most about finishing a preparation task with little friction. A facility staff member may care about whether the template reflects their actual instructions and can be maintained safely. A reviewer may care about privacy, product status, and whether the product makes medical claims. The project cannot treat any one of those concerns as an afterthought.

This changes the project-manager’s job. Instead of collecting “requirements” and disappearing into a build phase, I need to map where value can be lost: unclear instructions, a code that cannot be redeemed, a lost offline checklist, uncertain ownership, or a feature described publicly before it has been tested in its real setting.

The result is not more meetings. It is better questions before a technical decision hardens.

Create, Deliver and Support: design the work around the product

Create, Deliver and Support (CDS) makes the operational design explicit. It asks how teams, workflows, suppliers, information, tools, and support mechanisms join up to create and run a service.

The CareReady architecture has a family-facing static PWA, a CDN and static hosting layer, an API Gateway and Lambda API, DynamoDB persistence, and an authenticated staff administration path. Listing those services is not the operating model. The operating model is knowing:

• who owns each path;
• how a failed redemption is diagnosed;
• how a template change is reviewed and communicated;
• what is stored locally versus centrally;
• how deployment is checked;
• what staff or families should do when the system does not behave as expected.

Those questions are equally relevant to less sensitive work. When I migrated a site from Shopify to S3 and CloudFront, the project included DNS and certificate ownership, CAA-record behaviour, cache invalidation, GitHub OIDC access, and the ability to diagnose a failed deployment. A page loading in a browser was necessary; it was not the entire acceptance condition.

High-Velocity IT: make speed observable and recoverable

High-Velocity IT (HVIT) brings Lean, Agile, DevOps, automation, resilience, and measurement into the model. Its useful challenge is: can we change quickly with evidence?

For me, that evidence is practical:

• tests exercise the implementation that will be shipped;
• CI gives an early signal before a release;
• deployment credentials are short-lived where possible, rather than permanent keys copied between systems;
• public repositories exclude non-anonymised source material and secrets;
• a project states its limitations before someone mistakes a prototype for a mature service;
• lessons from a failure become a check, a note, or a clearer boundary for the next change.

This is not “move slowly.” It is how small teams avoid the false speed of repeatedly rediscovering the same problem.

The MP operating model in one project view

I use the modules as complementary prompts:

• DPI: What are we trying to improve, who decides, what is the risk, and what evidence proves progress?
• DSV: Whose journey is affected, and where can the relationship or experience fail?
• CDS: How will the product be delivered, supported, owned, and understood after launch?
• HVIT: How do we make the feedback, release, recovery, and learning loops fast enough to matter?

That is more useful to me than separating “project work” from “operations.” The project produces code, but it also produces a changed service, a support burden, a decision history, and organisational knowledge. The job is to leave all four in a better state.

For clients and employers, that is the capability I want the public work to demonstrate: not just that I can organise a schedule, but that I can connect stakeholder needs, cloud delivery, operational constraints, evidence, and continual improvement. The underlying projects are public in the VEAI LAB GitHub profile, with a concise client-work introduction at hire-veai.com.

For current certification information, see PeopleCert’s ITIL FAQ, Drive Stakeholder Value, and High-Velocity IT. PeopleCert currently states that ITIL 4 and ITIL (Version 5) run in parallel during the transition, with ITIL 4 modules planned to sunset on 31 December 2027.