Are you missing a musketeer on your projects?

musketeerAsk someone which delivery roles are critical to successfully completing a project and you will get a wide range of recommendations. Three of the more common roles likely to be stated include a project lead, a requirements lead and a solution lead. This is logical as the first is responsible for the delivery process, the second what needs to be delivered and the third how it will be delivered.

But aren’t we missing a vital role on most projects?

Sponsors are funding our projects to realize expected business outcomes and these outcomes are achieved through successful change implementation and not just by completing project deliverables.

Your core delivery team should be the Four Musketeers instead of the Three Amigos through the addition of a change lead.

On small, low complexity projects, a person fulfilling the project lead or requirements lead role might be able to wear more than one hat and take on a change lead role but the same reasons apply for not doing this on larger, more complex projects as would for combining the project lead and solution lead roles.

It’s a question of both capacity and capability.

The more complex a project, the greater the likelihood of the project or requirements lead focusing on the current stage and progress of the project and its deliverables rather than planning and preparing for successful change adoption and sustainment. While they will be actively engaging with stakeholders, the conversation might not stray into post-project topics. While good project and requirements leads are expected to possess advanced soft skills, the emphasis on specific soft skills required to be a successful change lead will vary from those for the other roles.

Looking beyond delivery risk a change lead has the ability to elevate the visibility of execution and operational risks caused by or impacting a project. One example of these is change storms which result when multiple projects and operational events impact a specific stakeholder community within a short period of time.

Change leads are more than just a nice-to-have role on most projects, yet are often ignored or eliminated through a myopic focus on cost containment.

You get what you pay for.





Categories: Facilitating Organization Change, Project Management | Tags: , , , | Leave a comment

Paying down technical debt should be like fixing ball marks on a golf green

golfmarkrepairMost companies have a fixed human and financial capacity for project work, especially if for internal work. Unless they hold a monopoly in their market, their ability to increase project portfolio funding is constrained by multiple factors including market growth opportunities, price sensitivity but to a great degree by their operating expenses. Assuming a fixed budget, the more the organization spends on keeping the lights running, the less is available to deliver change. While there are multiple causes of high operating expenses relative to one’s competitors or industry benchmarks, one of the most challenging to control is technical debt.

Technical debt is normally defined as the long term costs resulting from short-sighted decision making. While projects are not the only source of technical debt, they can be one of the worst contributors to it.

Finance departments often budget for operational costs or resource utilization using previous results as a baseline – this ignores the puts and gets from those projects which implemented changes over the previous year. When technical debt avoidance and reduction is not an area of focus, each year’s projects will increase the operational burden, further reducing how much change can be implemented. In short, the more we deliver inefficiently, the less we will be able to deliver in the long run.

Two common causes of technical debt are sticking with a given technology beyond the point where the benefits of doing so exceed operational costs and investing insufficient effort in quality practices.

Both of these causes can often be traced to unrealistic deadlines or the obsession with reducing short term costs. The former causes teams to cut corners in quality practices or to avoid innovative solutions in favor of tried, true and inefficient approaches whereas the latter can reduce appetite for investing in learning newer, efficient technologies or automating highly repetitive manual tasks.

One example is the resistance of a project sponsor or funding bodies to incur the costs or schedule impacts of developing automated test suites for an existing application as part of the scope of an upgrade project. While that one time investment might help the ongoing support and evolution of that product by reducing or eliminating manual regression testing, if the project team feels under pressure to hit an aggressive deadline or has tight cost constraints they will continue to perform manual testing and won’t do their part towards paying down technical debt. Even worse is when a new solution gets developed without operational efficiency being a priority – in that case, the level of overall technical debt will just continue to increase.

We need to apply the same foresight to paying down technical debt as etiquette recommends for ball marks on golf greens. Not only should we fix the marks we’ve created, we should also fix one or two others.



Categories: IT Operations, Project Management | Tags: , | Leave a comment

What determines when project planning is just right?

foggyhighwayI’d written previously about some similarities between baking and project management, but a key difference between the two is that even a novice baker can procure the right ingredients, follow a plan step-by-step and still manage to achieve a reasonably tasty outcome. Unfortunately with projects, there is no set recipe. That is the Achilles Heel of many project management development programs – they can do a wonderful job of teaching you how to correctly execute certain practices but gaining the wisdom to know when is the right time to apply a given tool usually only comes through personal experience or support from a coach or mentor.

This is evident when it comes to the level of detail found when planning for a given project. What might be too much planning on one project is not enough for another. And this doesn’t even account for our stakeholders’ perceptions and biases – some might get irritated with even the smallest amount of effort spent on planning activities whereas others will want activities broken out on an hourly basis and won’t be convinced of the low value in doing this.

While it might be difficult to come up with an objective operational definition for this, here’s one ratio to consider when deciding whether it makes sense to keep planning: (Assumptions which can be efficiently validated/Certainties). When our team is faced with a large number of assumptions which could be confirmed with a little more effort, it’s likely worth investing that effort to increase our level of certainty. However, if the volume of assumptions which won’t be validated anytime soon is increasing dramatically, it’s probably time to stop planning beyond a high level of detail.

A couple of other factors to consider include the degree of similarity to projects from the recent past which our team has delivered and the size, duration or complexity of the project. The danger with these factors is that they can lure us into a false sense of security. Just because a project looks a lot like one we’ve worked on before, if we plan it to a microscopic level of detail, unconscious biases might cause us to ignore evidence of an unforeseen risk being realized.

Finally, one can attempt to analyze the costs of insufficient planning – if those are lower than the direct and opportunity costs required to plan to a lower level of detail then it’s worth stopping.

The uncertainties we face on our projects are similar to the unknowns that might be just around the corner when driving on a foggy highway at night. Planning is similar to the headlights on our cars. If we drive at a reasonable speed, they will provide us sufficient warning of the dangers ahead. On the other hand, if we drive faster than the relative visibility provided by our headlights it will be as risky as driving without any lights on.






Categories: Project Management | Tags: , , , | Leave a comment

Create a free website or blog at

%d bloggers like this: