Photo by Daniel Abadia on Unsplash

Is Your Project Really On Track?

As program manager, one of the most important responsibilities is knowing if your project is on track. Typically, we all follow the same basic thought process when confronted with this question: we review our project plan or feature roadmap, check if we are meeting our milestones in terms of dates and deliverables, assess if we are staying within our budget, and evaluate if we are aware of any high-impact risks. If all these factors are in line, we can assume that the project is ‘On Track.’ However, the question is, is this enough to ensure the success of the project?”

I’d like to introduce a more structured approach that will help you to confidently report on the status of your project. This approach will ensure that you can answer the same question with a high level of certainty and clarity.

Multiple Dimensions

What do I mean by multiple dimensions? Well, I am speaking about the various aspects that make up a project, such as sponsors, stakeholders, deliverables, teams, resources, timelines, budget, risks, customers, and products. Each of these aspects represents a dimension that should be considered individually (a dimension). The combined result of these dimensions will provide you with a comprehensive overview of your project.

I am sure you already knew all this, so what’s new? Well, I propose we evaluate the health of each dimension separately, dig deep into the heart of them, and then answer the original question (“Is your project on track”). With that idea in mind let’s start exploring some of those dimensions.

Sponsors — we consider a sponsor any organization or persons who have ownership of the project or initiative. Their role is to provide necessary resources, support, and leadership (vision / mission), which represent the program and its goals in all aspects. So, how is the sponsor part of the status? As program managers, it is crucial for us to regularly assess the level of importance that the initiative holds for our sponsors and their level of commitment towards it. Any alterations in sponsorship, be it changes in interest, organizational structure, corporate politics, leadership goals, or shifts in market strategy, should be treated as high-risk event, and we need to assess the impact to the project. For example, a change in priorities could mean that in the future the program budget and resources will be constrained, or it could mean that now the program needs to be delivered faster than originally planned. So, let’s get ahead of problem and define a KPIs to track our sponsors. I like to use the term “Sponsorship Health” with status Green/Yellow/Red and a trend: up/down/no-change. How do we track it? by being in constant communication with your sponsors through status and planning meetings, ad-hoc updates, and other ongoing interactions. It would be a mistake to assume that emails, reports, and offline communications alone are sufficient. In-person (or virtual) interactions provide an opportunity to gauge the situation and gain valuable insights by “reading the room”.

Stakeholders — Equally important as your sponsors, stakeholders hold many categories in a project. There are vendors, influencers, providers, governance, customers, etc. and each of them will have either positive or negative impact in your program. Your stakeholder roster should be a “live document”, it will evolve organically throughout the life of the program so stay on top. Monitor levels of interest and influence, priorities, and again consider all possible signals depending on the category. For example, if a “provider” wants to review their agreement, read in between the lines, understand what changed and why the change. Assess the risk and track it. Changes from your stakeholders in the level of engagement, participation, organizational changes, attrition, and focus are all signals that need to be on your radar and trigger alerts accordingly to the situation. For my stakeholder’s KPIs, I use “Stakeholder Health” with the corresponding subcategories. Same as previously I use G/YR, plus a trend (up/down/no-change). Write down the list of signals that you are monitoring so that you can evaluate them in a programmatic fashion and not miss one by accident.

Budget / Timeline — I am putting these two together because they are really the most obvious and easy to track. They give us a great insight: are we on track spending what we planned by when we planned, or not? If the answer is yes, most likely you are good. If the answer is no, quickly understand if your program is at risk of going over the assigned budget or the opposite, under budget could indicate that some planned activities didn’t take place and the program is at risk of falling behind. Or simply, that the activity is no longer required. Either way, understand the situation and develop a plan to get back on track. Again, the KPIs to track budget and timeline are fairly simple. For the financial aspects I like to track “spent to date”, “projected spent”, “variation”, and “trend”. And for timeline I track “schedule accuracy “, “status (on track/ahead/behind)”, “trend”, and then assign the category a G/Y/R value.

Delivery Teams — wait... what? what do I, as a program manager, have to do with teams? Isn’t that the “dev manager” or “resource manager” role? Yes, you are correct. But that is not what I mean. By “delivery teams”, I am talking about the resources assigned to your program, and what I track is the “health” of how those resources collaborate, participate, and interact with each other. A high performing team usually challenge each other but at the same time support one another. A team not so healthy will struggle working together, communications will breakdown, and their productivity will drop. And that is what you should monitor it. Remember, delivery teams are the most valuable resource, and you must do your best to enable an environment where they can do their best work and grow in the process. By attending to some of the team’s planning sessions, stand ups, demos, and retrospectives you will get an insight on the team’s dynamic and will easily spot any potential risk to the program. Also, Gaining an understanding of the metrics tracked by the team throughout their development cycles: velocity, sprint variance, burn-down, backlog behavior, sprint goal, and estimation accuracy, will offer an initial data point about the team’s performance. However, when taken together, these metrics can provide valuable insight into the overall health of the delivery team. In this case I track multiple KPIs. I work with the Scrum Master, or if there is none then I do it myself, to collect all the important “sprint metrics” (some mentioned above) and then I use my own “insights” from observations to assign a “G/Y/R” value and accompany that with a “trend”, of course.

Customers / Product Owners (PO) — We must keep present that whatever product we build should deliver value to our customers. Value is usually defined in term of addressing a need, resolving a problem, or just delivering something innovational. If our product does not deliver value, then most likely that product should not exist.

Product owners usually act as a proxy for the end customer. Product Owners (PO) understand the customer needs and translate them to specific features and requirements. And that is where we need to start paying attention. As program managers we need to assess and constantly make sure that the PO is spending enough time with their customers and can accurately represent their needs. How do you that? well, take the time and meet with your PO, ask probing questions, challenge and propose alternatives. How the PO reacts, and answers will give you a great insight on how well she/he knows their customer and the problem we are trying to solve for.

In agile methodology, the PO will be the person accepting the first “minimum viable product” (MVP), and all the following features. Without going into all the details of “Agile” methodology, it suffice to know that products are built in short multiple incremental iterations, and it is the job of the PO to validate the results at the end of each cycle.

And this is the point where you as the program manager need to pay most attention. The feedback that the team receives will indicate how well, or not, the project is doing. Positive feedback and very little change are ideal, but it never happens. If the project is going well, the PO will provide some positive comments, ask for small changes or adjustments, and provide green light to move into the next iteration. The opposite, large amount of feedback and change requests, will indicate that the project can be in trouble if adjustments are not made. When the PO provides negative or neutral feedback, introduces fundamental changes, or requests rework, all of those are signals indicating that there is a communication and alignment problem, thus the team needs to get together with the PO and get clarification.

If this type of misalignment is not addressed promptly, it will introduce schedule delays, budget overruns, and resource management issues that will throw your project into spin.

So, how do I track it? I use a couple of basic KPIs to measure “PO Acceptance”. I keep record of feedback (positive/neutral/negative), size and amount of change requests, and new features for future development. These metrics accompanied by a trend will give you enough signals on how well the incremental product deliverables are meeting expectations and whether the project will remain on track or is at risk.

Conclusion

Based on my experience, the degree of involvement required in tracking program details may differ from one project to another. In certain instances, when the project is straightforward or well-known, it may not be necessary to monitor the details so closely. However, in situations where the complexity rises and you are operating under a tight timeline and budget, it becomes critical to delve into the intricacies of these “dimensions” to stay ahead of the game, recognize and respond to any potential risks that could jeopardize your success. Wishing you the best of luck!