Ensure an informed sign-off of the requirements definition
You might suppose that this step was added to round out the steps to ten. Surely the user knows what is required, or the project would not have been approved, planned and funded. But a lot happens between concept and definition.
At the time of writing this blog, the Federal Government is still struggling (after more than a year) to pay all of its employees regularly and accurately with a new payroll system (Phoenix) designed by one of the world’s leading technology firms. Yet Payroll is one of the oldest computer applications. People work, for salary or wages, under contract or fee for service basis. What’s so hard? Well, as IT people understand all too well, the devil is in the detail.
If the IT department, or a third party, is to be held responsible for delivering a working system, then it is essential that the requirements definition is accurate, and complete. (It should also be relevant to business needs, unencumbered by trivia and embellishment.)
Generally, requirements are written by IT specialists, through interaction with the business users. An effective process uses broad-based questioning, process observation, as well as generic research of the application domain – how other enterprises deal with the topic. The status quo should be questioned. Can the process be re-engineered as well as (re)automated? The greatest strategic benefits from computerization come from innovation, not automation alone. Of course, some of this questioning should have occurred earlier in the project, but that doesn’t mean it’s too late at this stage. But it certainly will be after this stage.
The requirements definition phase often takes longer than planned. There are two main reasons for this. Firstly, it requires the time of business users who are busy doing the job, as well as helping describe and/or document how they do it. It’s extra work and, typically, lower priority. Secondly, the complexity of the process is frequently underestimated, by both the user management and the project planners. (See Phoenix, above)
Any delay to the project schedule puts pressure on the user sign-off function, which is also often scheduled for a briefer time than required, because again the users, and user management, are still busy doing their jobs.
All too frequently, the requirements approval process involves presenting the user management with the document which the IT department or the outside vendor will use to develop the solution. Inevitably, it will be nuanced more to the technical than to the business function. As such, users often make assumptions of its meaning that the technicians might not infer. It is these innocent assumptions which lead to the all too frequent Change Requests which drive development delays and cost overruns.
A better way to achieve informed buy-in to the requirements is to have them presented, through workshops. Yes, it takes time that nobody can afford. And yes, it’s hard work to explain a future to which the users have not yet been exposed. It’s the beginning of Change Management and as we explained earlier, it’s time consuming, but essential.
This aspect is particularly difficult because the process requires participation of both management and front line staff who sometimes feel uncomfortable discussing issues in front of each other, let alone in front of techies. The CEO’s role is to make all parties comfortable with the idea of open and free discussion, for the greater good.
The time you spend in this process will be reflected in the success of the project, the functionality of the solution and the cost and time overruns. Give it its due.