Mandatory means Mandatory!

In one of life's strange ironies, last week, the day after I put up a post about the appropriate level of analysis for IT project, I was given a project that has been staggering along for 18 months (I shit you not) all because of inappropriate levels of analysis being applied. Now that this slow-moving train wreck has been handed off to me, I can see its doom was sealed almost from the get-go.

The initial two-page scope document for this project (which is about to celebrate its second Christmas) gives a few dot points about the business problems that need to be solved and then declares that this will be solved by updating some databases and developing a custom application.

This may not sound so serious to people who haven't worked on IT projects but declaring what the solution will be before you even adequately describe what your requirements are is a recipe for unmitigated disaster. This is known in the industry as the "Ready, fire, aim" approach except this is a little worse than usual in that someone shouted "Fire!" 18 months ago and now it's my job to tell them that they have to take aim.

It was actually mildly entertaining to see the look in the manager's eyes as I told him all of the work done in the last 18 months was essentially in the wrong direction and I was going to have to start from the beginning. He very quietly and slowly said "That's a little disappointing," but he looked a hell of a lot like he was going to have a stroke.

But that isn't my topic for today. Part of the conversation I had with the previous Project Manager when this dog's breakfast was being handed over to me was "Be careful when you're defining requirements because the business users on this project have a tendency to say everything is mandatory." This is a common complaint from IT developers, they're told everything is mandatory but then they're starved of time, resources and budget to actually achieve these supposedly mandatory requirements.

It is certainly common for business users to insist "everything is mandatory" and if this happens it becomes the Business Analyst's job to define what's really mandatory and what falls under "really, really important". The first helpful advice I'll offer in this area is to define terminology. The usual scale for importance of requirements I follow is:

• Mandatory - The project will fail if this requirement isn't met. You'd be better off not starting the project if you can't meet this requirement. In cases of software procurement, not meeting this requirement would totally rule a particular software package out of contention.
• High - A major factor in how successful a project will be. This would deliver major benefits but is not absolutely essential.
• Medium - Nice to have. Not having this feature would not have a major negative impact.
• Low - A bonus. This requirement should not be a significant part of deciding whether or not the project goes forward.

The next big task is often dealing with someone from the business who still says all 200 requirements are mandatory. In cases like this, really put them on the spot. How are you dealing with this situation now? Why is it not viable to keep handling it the same way? What alternatives are there? What would the impact on the business be if this requirement wasn't met? If someone can't quantify why something is mandatory then it probably isn't. Mind you, if they can quantify why it's mandatory, you probably have to go along with it, no matter how painful it seems.

And the really important thing to remember is mandatory is mandatory! It's rarely a good idea to leave a mandatory requirement until the last minute. Even if you think it will be easy to manage, it's better to be sure of this early in a project rather than later. Nasty surprises are easier to manage when you have a bit of time up your sleeve. I'll illustrate this with a couple of recent examples from my life outside of work.

Regular readers of this blog would have seen my recent venture into "Agile comedy." This was essentially treating a stand-up comedy competition the same way I would an IT project and going through multiple quick iterations to reach the end product. (I didn't win that competition by the way, the winner goes to air this week and I'll be very interested to see them.) One of the mandatory requirements I ignored until pretty much the last minute was that the video file submitted had to me smaller than 5MB. I thought this would be easy but it turned out not to be. I eventually delivered on this requirement within the deadline but it resulted in quite a bit of unnecessary stress. On the plus side, I now know I can punch my PC screen very hard without damaging it.

My other experience revolves around the holiday I'm planning for January. I had to book flights, accommodation and a vehicle, all of which I did quite methodically. Now, I'm going to New Zealand so another mandatory requirement is a valid passport. I thought I had this under control BUT I DIDN'T CHECK. It is not a good idea to let mandatory requirements slide. It turns out that my passport expired in September. So added to my normal Christmas rush is the stress of trying to get a passport renewal through quickly at the busiest time of the year. It should be all sorted this week but I caused myself mountains of unnecessary stress by ignoring an absolutely mandatory requirement.

So the moral of the story is, be sure of what requirements are really mandatory and identify the difference between important and mandatory. But once you're sure of what's mandatory, you can carve this in stone: Mandatory is Mandatory!