Leon's CRM Musings: The Iron Triangle and its Effect on CRM Projects

[Blog bot]

Источник: http://leontribe.blogspot.com/2014/0...ct-on-crm.html
==============

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.



Источник: http://leontribe.blogspot.com/2014/0...ct-on-crm.html