‘Because I don’t know what I don’t know, how can I produce a useful business requirements document with enough detail in it to ensure we get the business solution we need?’
Business software projects have traditionally been delivered by going through the following steps:
- business requirements
- process and functionality design
- install and build
- go live
It is hard to argue with this approach as it has been used to deliver successful business software systems for many years. It is therefore not surprising that business decision makers and software vendors insist on this methodology for software implementation. However it should be noted that many unsuccessful projects have also used this methodology. A particular methodology will never ensure success.
Traditionally software systems have required this approach to ensure a detailed roadmap can be followed by the various IT and business experts who will be building and installing the system. Having changes made part way through a project is typically time consuming, disruptive and expensive.
But as the person responsible with the task of identifying what my business needs are, I find myself worrying that I have not thought of everything. The outcome of this is that I will either put everything I can possibly think of into a requirements document or I will leave out vital requirements that I have not thought of. So when the project fails to deliver, it will be all my fault!
As a CRM consultant I am often faced with a request for proposal (RFP) document from a prospect that is obviously a cut-and-paste of requirements found on some internet site that does not seem to reflect the client’s actual business. These RFPs are useless to the software implementation partner and the client business alike.
So how can a business person identify the business’s needs correctly? The answer is that it is almost impossible. Unless this person has prior experience with a similar software solution with a similar business it is going to be difficult to get everything right the first time.
However there is an alternative which I (and my company) have proved works for the majority of clients that have adopted an alternate approach when implementing Microsoft Dynamics CRM. The ‘agile implementation’ methodology only requires the client to outline in headline form their business problems, issues and improvements they wish to address with a software solution.
The implementation steps then become:
- install software
- configure and test stage 1
- demonstrate to the business staff effected
- go live with stage 1
- configure and test stage 2
- demonstrate to the business staff effected
- go live with stage 2
- and so on
This iterative approach is possible because of the front-end software configuration tools provided by Microsoft Dynamics CRM. Rarely are ‘code-cutting’ IT people required as most changes need to mould the software to the business needs can be done by the software consultant working with one or more business staff members.
Because the software solution is rolled out in easy to manage stages and can be added to or modified easily as needs change or are expanded on, the risks are minimised and the costs easily controlled.
There are some essential requirements for this approach to work:
- A business sponsor – someone responsible to see the project succeed.
- Business champions – these people will work hands-on with the software consultant to define and configure the software to meet the headline business needs. These people are consistently talking to the various parts of the business that will be affected by the new system and reflecting feedback in the configuration of the software.
- Time – The business champions must be given the time to spend on the project. This doesn’t have to be full-time but needs to be significant during the configuration stages.
- A software implementation partner willing, able and experienced to use this approach.
I typically find that using this approach helps the business to understand what is possible, and then by trying a certain configuration out, can test its effectiveness before committing to go-live with it. This becomes a continuous improvement project rather than a big-bang one. As each change is made and tested, more changes are thought of, added to the system, tested, etc. The business decides when to roll out changes to their live system so end-users are impacted in a controlled manner.
Successful software solutions have ‘change management’ as a key component. Using this approach, change management is naturally taken care of as the business is intimately involved from day one. Ownership of the new system comes naturally, as does enthusiasm for the system as the people who are going to use it are the people building it.
But what about budget? A good software vendor will be able to give you a ball-park estimate based on the headline requirements. The project proceeds on a ‘time and materials’ basis. It is then up to the business to manage the cost vs delivery as the project proceeds.
This isn’t as nebulous or as hard as it seems as the business is involved on a daily basis with the implementation and can see exactly what has been delivered each day and can therefore judge value for money. In the traditional approach all the cost commitment must be made up front by the business which often does not see the results of the investment till the end of the project. At that time, if things are not right you have no alternative but to keep paying till you get what you need. This is typically how software projects blow their budget.
This blog has given you just the bare outline of the agile approach to software project implementation. There are lots of resources on the net if you search for “agile implementation methodology”. Better still would be to talk to a business that has used this approach. You can also contact Professional Advantage if you want to know more.
You can read more about Professional Advantage and Microsoft Dynamics CRM here.