Introduction
In this multi part series, I’m going to uncover some of the aspects from my former life as a PRINCE2 project manager that I’ve carried over into Salesforce consulting. Coming from a waterfall background, I’m particularly sensitive to the areas where a stricter, more linear process would have benefited and I hope this series can bring the two worlds harmoniously together.
The Mighty Iron Triangle
All projects, whether they realise it or not, follow the Project (Iron) Triangle. Unsurprisingly, it’s made up of three corners:
Scope represents the deliverable of a project, or the actual outcome. Cost represents the allocated budget and Time represents the period in which you have to deliver. No single item on this triangle can be changed without affecting the others. For example, if you reduce the Time element, meaning the project has to be delivered in 1 week instead of 2, you may have to double your resource, which means more cost. Similarly, if you increase the Scope, it can affect both Time and Cost.
A project’s scope, budget and schedule will have been carefully thought out at the beginning and changing any one of these can have huge repercussions if they’re not managed properly.
When you’re directly handling a project’s implementation, you’re often faced with new requests, tweaks or changes from the customer, especially within an Agile workflow. During this time, can be very easy to forget the commercially signed off scope and accidentally accept changes that impact project’s triangle. While these small changes may be easy to deliver on time and without much impact to the budget, what happens if the new functionally doesn’t work correctly? What happens if you need to bring in additional resource to fix some issues? All of a sudden, these minor changes that were never commercially part of the contract are costing the project and cutting into margins.
A project’s budget is based on the delivery of an agreed scope against an agreed schedule. This also takes into account the profit margin required to maintain a healthy business. That last point is a big one as without a comfortable margin, a company will struggle to keep the lights on and more importantly, pay it’s staff. As with most things in life, it all comes down to money.
Projects are never static though. Everything can change throughout the lifecycle and resisting that would be a fool’s errand. That’s why every project should have a strong change control mechanism. Every team member should feel empowered to raise a change request with their project manager should they feel a shift in the triangle. Any potential change of scope should be immediately checked against the statement of work and if the requirement is brand new, a commercial agreement must to be signed off before work begins.
Where this can get sticky is when the scope isn’t clear and both the customer and supplier have different opinions on what is to be delivered. That’s why I’m a big fan of a design spec that all parties agree on. Statements of work are not always the most well written documents and when faced with this, I like to make sure the customer knows what they’re getting before a single minute is spent on building a solution. It’s a very waterfall approach, but it can honestly save time down the line.
And as they say, time is money.