“If the metrics you are looking at aren't useful in optimizing your strategy - stop looking at them.” Mark Twain
“We are what we measure, and we measure what we see”. Bill Holmes
Can I have a well-run project that delivers an unwanted product?
There is a difference between project scope and product scope. When I use the term “product”, I am applying it broadly to include the deliverable as described in your scope statement, even if it isn’t a retail product. The “project” is the work required to deliver the product.
For a waterfall, or predictive project, we follow a process to develop a detailed project plan. We assist in the development of the Charter, which often describes the high-level scope, cost, schedule and purpose of the project. We identify stakeholders, assess their attitudes, and develop a communication plan to meet their needs. We gather requirements and decompose those requirements into work packages where we estimate the resources we need, the cost of those resources and how long each package will take. That information eventually becomes the scope, cost, and schedule baseline. We may also develop plans for risk, quality, resources, and procurements. When we are done with all that, we place the entire plan under integrated change control and it is “baselined”, meaning a change request is needed to modify plan governance.
Then we manage to the plan.
Think about project governance in your organization. Don’t you put in place dashboards that report the progress of the project. Aren’t you asked if you are within budget? Will you finish on time? What does your quality look like?
Those are transactional questions that focus on project scope and performance, not the product.
If you are using an Agile method, you work with the customer to understand the project scope as described in the Charter. You then develop a Product Roadmap that describes, at a high level, what functionality will be delivered and when. Those “releases” (or minimally viable product) are used to develop a sprint schedule, and the Product Owner works with the development team to identify the highest value requirements to be delivered in each sprint. The theory is that by using short development cycles and providing working software to the Product Owner, feedback is constantly being incorporated into the next sprint and highest value requirements are being provided to the customer incrementally.
In both methodologies it is crucial that either the Project Manager or the Product Owner remain focused on the purpose of the project. As described in an earlier post, projects are started because there is a gap between the current state and the desired state. The business case should describe the strategic alignment of the project, and that is captured in the benefits management plan which describes what capabilities are being delivered and when.
That is crucial. The purpose of a project is to deliver business value. Don’t forget that as you are tactically executing on the plan.
The next post will do a deeper dive into product metrics.
Coda
How many of you work for organizations that explicitly state that they want to be “data driven”? That term is as in vogue as “synergy” was a decade ago. We also say that we want “input from our employees” because we can learn from those “closest to the work”. But does the organization really want that? For everyone in a leadership position, remember you are judged by your actions, not your words. Even if you hold “townhalls” or “listening sessions”, if you issue key and controversial edicts with no discussion or input, it shows that you really don’t care what people think. Decisions aren't being driven by data. They are being driven by personal opinion.