Go and ask for a quote for an IT solution delivery, and the first thing you get asked is: "What is the scope?" Seems fair - if you want to get a price commitment, you will be asked for a functionality boundary. But what does this actually do to the delivery of your solution? Nothing good, I'm afraid. You have exchanged uncertainty and risk for limitation and disappointment. How? And more important, how to prevent this? Read on.
How scope creates a prison
In the traditional project delivery, where the solution is a complex set of features with many interdependencies, setting a scope is essential. As a customer, you get some clarity of the functionality you get, and as a vendor you get some understanding of the cost and effort it takes to deliver that functionality. However, simply because there is nothing better, does not make it a good system. Just look at the number of projects that go "over budget". There are many articles written about Scope Creep - the worst kind of creep you can have on any project. But is it?
Consider that the customer does not always know what is being asked. Typically in these projects, the delivery is a much newer solution, newer technology, than what the customer already uses. The further along the project, the clearer the delivery becomes. That is a problem when the scope is set at the beginning of the project.
It creates a prison for both the customer and the vendor. From the vendor's perspective, the scope is the MAXIMUM delivery as agreed with the current budget. Ask the customer, and then the perspective is the MINIMUM features delivered. If you were to draw a Venn diagram, the circles only intersect at one single point - no room to maneuver.
Scope on a Time and Material Project? - we need to talk
There are two main contracting mechanisms in a traditional waterfall project. Time and Material, and Fixed Price. Other machinations, such as Time and Material Cap, and Flexible Scope are nice inventions, but they create more problems than they solve.
Engaging on a Time and Material project? You have to understand what you are buying. As the name implies, you buy time... and material. In other words, your bill constitutes of the time spent by your vendor, and cost made. Regardless of what has been delivered - A statement of work is the initial guidance to the focus of delivery effort, not a contractual agreement to what will be delivered against what cost (typically, you do not see the cost or time budgets in a Statement of Work for a Time and Material project - at least, not if your vendor knows what they are doing).
Swimming in a straight-jacket
Ever tried competing in a long-distance swimming contest in a straight-jacket? I would not recommend it. Similar to delivering a long and complex project, where from all angles, additional constraints are introduced. Each constraint just adds another strap, each concession pulls the straps tighter.
A fixed-fee project is probably the worst form of risk-mitigation from a customer's perspective. As a customer, you might expect a fixed fee project to have all sides of the iron triangle fixed. Every project manager worth their salt knows that that simply can never happen. No, the vendor simply sells you an "insurance" that "fixes" the scope and time section. Basically, you are paying for the flexibility of the sides to move.
But when you do add scope, this is where you get the variations, the change requests, the pieces of paper that exchange that additional scope for additional funds. Given that the project most likely already is costing more than initially thought (risk reserves have a way of making things more expensive), you have to start working at trade-offs - but taking things out is never an equal trade to putting new things in.
How to retain flexibility, and manage risk?
Reading the above, that combination seems completely out of reach. And to be upfront and clear, there always is an amount of risk in any project, or delivery. The question is - what risk is acceptable, and how are you going to manage it?
There are more ways to manage risk than to buy an insurance for it. But it does depend on the relationship between the customer and the vendor. If this relationship is combative, each trying to get the maximum out of the process - playing the "I can only win if you lose" game - then you should not explore the below.
If you have a vendor that genuinely wants the best result for you, the customer. And as a customer, you genuinely believe in maintaining a long term relationship with your vendor as a trusted advisor, then this might be the solution for you.
First - we need to establish the capabilities that the business requires. Each capability may already have a system attached to it, which may need to be replaced, or integrated with. Then the user stories are documented (it is much preferred to document user stories, instead of requirements, as it provides clarity to what can actually be achieved). Each story is added to categories Must, Should and Could have. It starts to sound a lot like an Agile method, but that does not need to be so. You can use this method to deliver waterfall type projects just as well.
Finally, you have to agree, how to manage the project - what is the Iron Triangle; which side do you fix, manage, and sacrifice? For example, you could fix Time and manage Budget - that means you deliver what you can in a particular time, against a mutually agreed budget (with possible adjustments) - but both parties accept that the delivered feature-set is sacrificed. Similar if you fix the budget, and manage the feature-set (a great tool to manage is the ability to sacrifice Could and then when needed Should have items) - you just cannot guarantee a certain delivery date. Agreeing on the management of the Iron Triangle is essential before commencement of the delivery. It should be documented in the charter and brief, so it can be referred to at a later state.
What if it is too late? Is my project salvageable?
Sometimes, things just don't work out - sometimes things just spin out of control. In projects, there are three options.
Option 1 is to continue and hope for the best.. not a good idea. At best, you stay on the current trajectory of failed delivery or loss.
Option 2 is to get the lawyers involved, and start dissecting the agreements and contracts. Also here the outcome is not a salvageable one. Choosing this pathway is a guarantee the game changes to Win/Lose, and the outcome is far from certain - other than nobody gets out better.
There is a third option - assuming both parties are of good faith - and that is to get external mediation to find the common ground. It may be hard to imagine during such tense period in the project, but common ground is in most cases not too far out of reach.