There is a wisdom amongst project managers called the Iron Triangle.
In essence, of the three parameters of scope, time and budget, you can control two of them but not the third as it becomes a function of the other two. For example, if you control the scope and the time, the resources required become fixed. It is a case of working out what you can live without controlling. In this framework I thought it is worth considering common methods for delivering CRM projects and the pitfalls inherent in ignoring the triangle.
Agile CRM Projects
“Agile” is a project methodology, which seeks to deliver a high quality result through high-interaction with the customer and iterative development. It is common in bespoke coding projects and is creeping into CRM projects more and more in recent years.
I have seen my share of successes with Agile but, more often, failure. Let us consider why.
Agile is often sold as a superior methodology with all upside and minimal downside but this is naive at best and downright dangerous at worst. There is no question an agile methodology, if employed correctly (i.e. very high levels of collaboration between the client and the developers), will deliver a high quality result. However, where Agile projects are often considered a failure is with the blowout of time and resources.
If the client is not given a voice to articulate their requirements or, if the client does not have a clear, precise vision of their needs, agile projects drag on gobbling up budget and time. The end result, assuming there is one, is a product which is built as requested but not as required. The fit is poor to the business’ strategy, the end user needs and, inevitably, the product dwindles into non-use.
Often, the solution to the blowout is to ‘time-box’ the project, that is control the schedule AND the scope. From the iron triangle this fixes the required cost/resources. If these resources are not available or if the budget is not there, something will give and the project, again, has the risk of being considered a failure.
Waterfall CRM Projects
Waterfall is the ‘traditional’ method for delivering CRM projects and comes out of the construction industry. The objectives are defined up front, the solution is developed and then it is tested for compliance at the end. Strictly speaking, one does not move to the next phase of the project until the previous one is completed i.e. you do not move to development until the design is complete. However, this is often impractical in practice, leading to some to call CRM projects “Agile/Waterfall” when feedback is introduced into the project ‘on the fly’. As far as I am concerned, there is little Agile about these sorts of projects; they are simply Waterfall projects with some healthy communication.
Even in the most Waterfall of projects there is always adjustment. If we consider a very traditional Waterfall project, like building a house, while it is true that the architect plans are drawn up before the foundations are laid, there is also a bit of ‘creativity’ employed as the project progresses.
Waterfall defines the schedule first and the scope and therefore, like Agile, this imposes restrictions on the resources/budget. If the budget does not meet the lofty goals of the scope, problems will occur. One drawback of Waterfall is there is much less interaction between the client and the development team during the building phase of the project. The idea being that the scope is well-defined and, therefore, guides development.
After development takes place, the testing phase ‘sanity checks’ the solution to make sure what the client understands to be in-scope matches the solution. If there are gaps (not unusual), negotiation ensues to determine whether the gap needs to be plugged. An adjustment to the scope means the other sides of the triangle also get tweaked (cost and schedule). As testing comes towards the end of the project it is often the schedule which is seen as the biggest casualty.
Again, a poorly defined scope means changes down the track but, with a good change request process in place, it is not a disaster, assuming the resources and budget are available to cover it. If it is not clear, my personal bias is to lean towards Waterfall for CRM projects but I can see how, for a client with a clear strategy and requirements but poor product knowledge, a carefully controlled Agile approach can work (and has for me in the past).
Like an Agile project with poor scope communication, if the scope is poorly understood by the client, the project gathers dust on a virtual shelf and never reaches its potential.
Conclusions
It is very easy for a client, especially one with little experience of software projects, to believe they can lock down the scope, schedule and budget of the project. In reality, a project never understands these three elements perfectly and, regardless of the methodology employed, adjustments need to be made and pragmatism must be employed.
When the client or vendor choose to ignore this and try to break the iron triangle, it is the project that becomes broken first. Either budgets blow out, schedules are violated or a poor, impractical solution is delivered. By developing trust between the vendor and client and respecting the constraints of the iron triangle, the perfect result may not be delivered but the optimal result for everyone involved will be produced and a relationship built to ensure the foundation delivered can be built upon in the future.
3 comments:
I was disappointed to see "Programming MF" missing from the list of methodologies.
I googled it at work with the boss over my shoulder. Turns out the 'F' does not stand for 'Foundation' ;)
I posted this on the internal Oakton blog and got told to consider agile by fixing cost and schedule but letting scope be variable. For a bespoke development project agile works exactly this way.
Unfortunately, for many CRM projects, especially the larger ones, they are won by tender with the vendor having to commit to a scope before the process starts. This is, of course, where the triangle predicts the inevitable problems.
One point I should emphasize is that scope changes are not the enemy. In a waterfall process where design and validation (testing) are so far apart, change is almost inevitable. The cause of the change can be from missing a design element, evolution of the business as the project progresses or from the client's better understanding of the underlying CRM product's capabilities. If the vendor and the client approach change with a mature attitude, it should be considered less of a problem and more of an opportunity I think e.g. "this element was out of scope but will deliver significant business benefit, return the cost to the business within a month and add an additional week to the project. Do we include it now or record it for a later phase?"
One thing which I realised in writing the article is that a client's poor understanding of the requirements (or the priority of requirements) is a recipe for disaster, regardless of the methodology. For agile, the client never considers the project 'good enough' and the iterations continue until the money runs out (or work stops) with an inadequate product delivered.
For waterfall, the initial design is flawed, leading to a flawed development and, at the eleventh hour, testing reveals gaps which require significant money to plug (and if a deadline is looming, impossibly high resourcing).
The best way, I believe, to mitigate this is to have strong business analysts/consultants at the start of the project to nail down the needs (not the wants) of the client as much as possible.
Tackle the needs effectively and any additional wants become possible iterations for agile and change requests for waterfall.
Post a Comment