This post covers the first key aspect of accelerating any project, which is to have a plan for how you are going to go about assessing and executing this change. I say ‘change’ because a request to accelerate the project to an earlier delivery date is a special case of a Change Request (CR) to an in-flight project. As such, the Acceleration plan’s pattern is similar to any Change Request that might come through from any party.
But the nature of the change is quite different from most CR’s and so the plan has some unique aspects to it. Bringing forward a delivery date is usually very contentious and can be quite disruptive to the team and their current mental framework. Time affects expectations more than any other change.
You will end up facing 2 options for how you go about planning and executing this change, based on whether you try to deliver the whole scope, or a reduced scope, at the earlier date.
No Change In Scope
Project Acceleration differs from other Change Requests in that the primary option to be assessed is no change in current scope.
Yes, that’s right, the major difference to a normal CR is that the base position for the change is no change in scope. Even if not explicitly stated, keep in mind that the implied constraint in any request for project acceleration is that you deliver the entire current project scope at an earlier date. The requester (typically the Project Sponsor) may reluctantly accept a reduction in scope or quality as the price to pay, but that’s not their preferred result (in most cases). Even if they don’t ask for it, you can bet it’s top of mind.
(Note: I can already hear the howls of protest from some readers, quoting the Iron Triangle that says you can’t change one of the triangle’s factors without impacting, ipso facto, the others in some way. At least for software projects, I personally don’t believe that the Iron Triangle is anything more than a concept. It has no practical application in terms of managing a project. I will post about this separately, but, for the purposes of this post, my proposition remains that the first and primary option in Project Acceleration is full scope delivery.)
In my view this is the preferred option.
Change in Scope
Keep in mind that changing the scope in order to deliver early is actually much harder than it sounds, because now you have 2 degrees of freedom instead of one. The worst-case scenario of this type of change is that you end up changing the scope but the final delivery date does not materially change (or even gets worse). I’ve seen this happen more than once, and it is very hard to control. This is because you do not have a defined scope change that has to be assessed, but you have an open-ended scope change question which invites multiple opinions and multiple tradeoffs.
This risk is much higher if you don’t have a good handle on the actual status (see next post), and you uncover some undisclosed issues as you go through the change process.
The plan for managing an acceleration change process is a three-stage process, rather than the typical two-stage process. If you are not familiar with the two-stage process for change management, then try reading this article. In this article there are five (5) steps mentioned, three of them are process dross or scaffolding (in other words they are just steps that are obvious and don’t really add any value to the process): only steps 2 and 4 have significance. they are:
- Impact Assessment; and
- Change Implementation
For Project Acceleration, I think that there is a three-stage process:
- PM Fast-scan Doability Assessment;
- Impact Assessment; and
- Change Implementation
PM Fast-scan Doability Assessment
The additional step is due to the significance and contention that always surrounds a reduction in available time. This step is usually performed anyway (usually informally and possibly unconsciously) for major Change Requests. But for acceleration, I’m calling it out as a formal first step.
Whether this step is performed informally or formally, it is usually performed with a very small group of people. it may only be the PM and say the senior representative of the most impacted team, and/or the Solution Architect if there is one. For the Project Acceleration assessment, I strongly recommend that it is done with as small a group as possible, and just by the PM if at all possible. the degree to which it is possible to be done only by the PM depends on their understanding of the project’s real status and outlook, and their understanding of the solution technology space.
The rationale for this is that even beginning the process of collecting info on doability is likely to trigger one or more of the impacts that you don’t want right now: interruption and disruption of current thought trains and activities, disquiet about potential change, or even panic. Timing of these thoughts is critical. I have an absolute policy of not hiding things from the team. But the job of the PM is also to insulate the team from unnecessary noise, and so there is definitely a short period where the PM will be doing initial assessment before moving to include others in the discussion.
That is why I call it a “fast-scan” assessment: it should be done as rapidly as possible and preferably in less than 24 hours.
The reason for this is threefold:
- as outlined above, the “unintentional impact” of raising the issue with the team at all;
- the need to assess two (2) impacts, not 1: first the impact of assessing the change, and secondly the doability of making the change; and
- the need to complete the assessment with the absolute minimum of team involvement.
In an ideal world, if the initial PM Assessment results in quantitative and (relatively) indisputable evidence that the acceleration is not possible at all (even with changed scope) then the proposal can be “nipped in the bud” and buried without ever impacting the team at all (or at least until post-project drinks).
How the PM does this “Fast-Scan Doability Assessment” depends on many things, and there is quite a lot of work to do: the longer the gap between the initial request and responding back to the Sponsor, the higher the chance that the request will become known to the rest of the project team, and you will have a different profile to deal with; one that is certainly more complex.
The first step is to truly understand the status and outlook of your project, and will be covered next post. Subsequent posts in this series will outline and discuss different approaches to this and other stages of the Acceleration change process.
Completion of the Doability Assessment
The end of this Doability Assessment is to respond back to the requester, and provide a definitive response from your assessment. There are only two options:
- Stop: do not proceed: the date has a very low probability of being met, OR the risk to the current project’s dates is too high; or
- Continue: go to the next stage of normal impact assessment
Note that the Stop recommendation is not a categorical ‘No’. you are not saying that it is 100% guaranteed that it can’t be done. You are recommending that the risks are high and the gains are low. The sponsor may insist that you proceed anyway.
This post turned out a bit longer than I planned, but it’s an important topic. from my perspective there are many reasons to consider that this acceleration process be performed based on delivering the current scope. It’s a lot less risky and far more likely to produce the desired outcome than it is to look at changing both scope and delivery date at the same time.
What do you think?