Educated in New Zealand, Michael achieved an Honours Degree in Manufacturing and Industrial Technology. Since then he has gone on to achieve Project Management Professional (PMP), PRINCE2 Practitioner and a Diploma in Business Analysis (ISEB).He has worked at the leading edge of the programme/ portfolio/ project control industry for 9 years and has experience working with Accenture, Unilever, London Stock Exchange, NHS, Morgan Stanley, Orange, TYCO and the Office of Rail Regulation.
I'm defining lust in the project context as:
'Unrestrained desire without consideration of the consequences'
In this article we will be exploring how scope creep, changing baseline requirements, late project changes, gold-plating and a lack of a change control system can cause you all sorts of project pain. We'll also be investigating how Scope Management (as the penitence) can be used to bridle these project transgressions that constitute lust!
In this article series I’m going to associate each deadly sin with some ‘project transgressions’ and then talk about an appropriate ‘penitence’ to ensure these sins are avoided in the future.
So lust (latin: luxuria) is defined as an ‘unrestrained desire without consideration of the consequences’. I see this sin as often starting at during project kick-off. The sponsor, and key stakeholders, have multiple, and often conflicting, scope requirements and they desire everything to be delivered as part of the project. More often than not a subset of the initial shopping list will be agreed and base-lined and the project will be initiated. Then as the project progresses new requirements will appear and previously excluded scope will suddenly appear back on the radar again. Then the battle of managing changing requirements and formally agreeing what is ‘in’ and what is ‘out’ becomes progressively more complex and the waters become muddier and muddier until the project has been ‘mortally wounded’ and finds itself in the unenviable position of facing the impossibility of delivering against the sponsor and stakeholder expectations.
So read the following descriptions and see whether these lustful project transgressions exist in your world:
- Scope creep / Lack of a commercial change control process – The requirement’s ‘goal posts’ are constantly moving. Scope is added on an ad-hoc basis in an uncontrolled fashion. Not everyone is apprised of the current baseline. No impact/benefit analysis is done before a change is added to the baseline;
- Gold-plating – You often deliver scope over and above what was initially ageed to either keep the client happy or try to ‘exceed their expectations’; and
- Unclear base-lined requirements / Too many changes occurring late in the project – There is too much room for interpretation in the originally agreed scope document and you find a lot of change seems to happen at the end of the project during build, testing and production.
If you read that list and found yourself nodding at each of those bullets then don’t worry as you’re not alone. Lack of Scope Management is cited as one of the key contributors to unsuccessful projects and certainly one of the most frequent sins. You are suffering from LUST! The unrestrained desire for additional functionality without consideration of the consequences!
In purgatory, the penitent walks within flames to purge himself of lustful thoughts...however for the purposes of this article we’ll focus less on the flames and more on a few pragmatic steps you can take to address these common transgressions. Let’s go through the appropriate penitence to free your project environment from lust, the first of our deadly sins....
Your penitence is to design, develop, implement and operate a robust Scope Management function. To read a short summary on scope management view the category link here:
http://www.decium.co.uk/categories/Scope-Management/
Now we’ll discuss specific actions you can undertake to put yourself back on the virtuous project path. These actions are simple to define but some can be very complex to implement so please don’t lose heart if you don’t have a fully functioning Scope Management function up-and-running by the end of the week!
Let’s investigate actions for each of the transgressions outlined previously:
Scope creep / Lack of a commercial change control process – Allowing requirements to change freely will seriously impair your project in the long run. As you increase the size and complexity of the work you are doing (e.g. you are running a programme) a lack of Scope Management becomes, exponentially, more important. You must clearly agree the process for inputting, analysing and signing-off change and ensure the appropriate stakeholders are intimately involved so they can both understand the impact of changes and their criticality.
It is imperative to get the change control process set-up as early as possible during project launch. The foundation of this should be a change control board with appropriate authority to agree changes on an as needs basis. A strong change control board with key stakeholders will provide both a conduit for modifying the scope baseline as well as an authoritative and informed gateway that can ensure unnecessary change is avoided.
Right, so what's next....
The next transgression has an innocuous exterior that belies a darkened core which can afflict even the most pious projects...
Gold-plating – This one is a classic sin in smaller companies, who have less leverage, and they find themselves in a position where they are desperate not to lose a client (who is essentially their lifeblood) so they will try to do more than was originally agreed because they hope it will impress the client and possibly lead to more work. Naturally this isn’t the exclusive territory of small vendors but also sullies the delivery of some of the big guns as well. Some people might read this and say ‘hold on…surely this is a good thing?...delivering more than was agreed?....exceeding clients expectations?’. I’m sorry but my answer to that is a simple…no. If you agree a scope and can deliver that scope more quickly/cheaply than you originally estimated then do it. The client’s expectations will have been exceeded. But if you decide to deliver a bit of old-fashioned ‘gold-plating’ then you are taking the decision out of your client’s hands. The decision as to whether they want that extra scope or whether they would actually prefer the project delivered early or below budget. This doesn’t exclude you from telling the client of your current, strong position and a discussion of whether some originally omitted scope might be added in to flesh out the budget under-spend. Let it be their decision. Deliver what you promised. Not more. If the amount they want you to deliver increases then so be it, but do it in a controlled way. In the long run this can only be something that increases the respect they have for you and your ability to deliver consistently. It also shows them that you are a project management professional and understand the intricacies of managing this most important of project elements.
I hope by this stage you can feel the weight of moral project turpitude lifting from your shoulders. Now onto the final transgression...
We can now approach the final transgression, which constitutes the deadly sin of project lust, in confident spirits...
Unclear baseline requirements / Too many changes late in the project – Before I launch into the penitence for this transgression I’d like to paint a slightly richer picture as less specific requirements documents (or project specifications) are often treated through the use of different contract types rather than being viewed as a negative. Let me give you a generalist’s view of the types of contracts used for varying levels of scope clarity:
- Fixed Price Contract / Explicitly defined requirements: The more time you spend defining exactly what has to be done the more accurately a vendor, or your internal project team, can estimate the schedule and cost. Therefore a fixed price contract becomes a reality as the risk of scope misinterpretation is greatly reduced and hence the vendor can be confident that any scope changes can be processed through the change request process.
- Incentive Share Contract / Key functional areas explicit but associated detail implicit: On the sliding scale of clear scope definition this is somewhere in the middle. The client has spent some time considering what is to be achieved, in terms of scope, but hasn’t executed a detailed plan and analyse phase to flesh out all of the lower level details. Whilst the risk is shared between the client and the vendor a reasonable estimate can still be made and the vendor is incentivised to deliver early/below budget.
- Time & Materials Contract / Implicitly defined requirements: With a scope document that sets out the framework of what is to be achieved but leaves room for interpretation the vendor will not usually want to commit to any type of contract apart from time and materials. The simple reason is that anything but a T&M contract would mean the risk profile for the vendor is significantly greater than the client.
So now you have the background and the theory I want to make some general recommendations regarding base-lining requirements. I understand the emotions and excitement involved at the beginning of a project and the near-desperation to get into the nuts and bolts of delivery from both a project team and sponsor’s perspective. However it is precisely for this reason that we should stop and take a breath. Remember the sin we’re talking about here? Lust… ‘unrestrained desire without consideration of the consequences’. Launching into a project driven by the errant desire to ‘get going’ without thinking about the adverse impact this could have further down the track is a project sin. So my recommendation is to put that emotion and energy into getting the scope as clearly defined as is practical before moving past the plan/analyse phase. The model for requirements changes throughout the project lifecycle has been widely promulgated and, in the interests of brevity, I won’t go through the whole model again but will give the main points. A change made at the analyse stage will cost about $1 US. If you only discover that change at the design stage it will cost approx $10 US, build stage will cost in the region of $100 US, testing is about $1000 US and finally if your project has gone into ‘production’ it can cost any where up to and above $10,000 US for the same requirement change. I won’t dwell any further on this point as I think the numbers speak for themselves. Try to spend as much time as possible on the planning and analysis phases.
The key technique to help you along this path is the trusty Work Breakdown Structure (WBS). This will help you structure your requirements so gaps become much clearer. There are so many good descriptions of the WBS out there on the web I’d recommend just popping the search word ‘WBS’ into Google and you’ll be buried in detail on how to use them and how you can make them work for your project.
Now to the conclusion...
So I hope there is some food for thought there to help you address one of the worst project sins…lust. With a robust Scope Management function in place you will be able to avoid some of the critical illnesses of failing projects/programmes/portfolios. However this will not be the panacea for all project issues. I hope that by following this series of articles you’ll be able to learn lessons you can either apply on your current project or make sure you put in place on future projects to avoid the aforementioned transgressions.
Please check back in next month (1st December) we’ll be investigating the deadly sin of gluttony….defined as:
‘Over indulgence/consumption of anything to the point of waste’.