Mandatory is 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!



Filed under Work

16 responses to “Mandatory is Mandatory!

  1. David

    The best way I’ve found to deal with the issue of users wanting EVERYTHING, is to force users to rank them – 1, 2, 3… Then you start working on item 1, then 2 …

    That take the pressure and responsibility off of IT and put it back where it belongs – the user. They are the owners and should be the ones who make those decisions.

    Yes, occasionally IT will have to override their decisions due to purely technical issues (ex, you can’t print reports before the data entry screens are created). But in my experience, if you explain the issue they will change the order themselves.

  2. Varad

    In consulting domain, most of the times its the IT people who classify the requirements. Most times users want something to work with and they think everything they want is mandatory. In such scenarios where the clients are not in good shape to classify the requirements, we draft them based on similar criteria you have suggested – why can it be taken care in the way its being done now, what are the impacts of not having it etc…

  3. David: an excellent strategy

    Varad: in my experience if the client/business/user can’t articulate what they want and they don’t have an analyst between themselves and the IT group then it’s a disaster waiting to happen.

  4. Telling people to take aim before firing should be started from college classes itself.

    I was always surprised when many of my friends back in college, when asked to write a program, would straightaway start coding and making some skeleton classes and then think how to make the classes do what they want.

    The importance of “Think before you act” really can’t be stressed enough when working with large IT projects. Funnily enough, many still choose to ignore it.

  5. This post is so close to my heart, i had seen this situation a couple of time:
    Where no one knows wht they are doing, but they still keep doing it until someone asks them to stop it…
    I wonder when will people stop working blindly…

  6. onkar: you’re right, it should be the first principle people learn

    plubius: yepp indeed.

    Kurt: sometimes it takes a little bit of guts to speak up.

  7. There’s something about this post that makes me not have read it yet. Is it the lack of kittens?

    I’ve read the title though, and it makes perfect sense!

  8. Aren’t kittens mandatory?

    Hey, I’m glad I’m no longer in IT full time and dealing with users or managers anymore. It just got really frustrating sometimes.

  9. Kittens are mandatory in certain situations. You will know these situations when they arise.

  10. When dealing with a lot of stakeholders I like to “freeze” requirements after 3 rounds of talks. The users ask you for something, you confirm it, they correct or give the green light, and then it’s set in stone. Changing whatever was previously agreed should be painful. Of course, a couple weeks later I send an email telling some users that we made some sacrifices and will code their features. Or not, bwahuhauhua. :p What matters is driving their expectations to reasonable levels.

    The root problem of “everything is mandatory” is usually lack of scope. Users should think that you’re making the software for them, down to a personal level, but in fact you’re developing something to meet the business demands. There’re a lot of people that think that they have the perfect solution for a business problem or just want to change things into their way, probably looking for a future meeting where their bosses will ask “Who put this on the software?” and they will rise and yell “I did! I did!”.

    The last part where I usually cut “mandatory” requirements are those process currently made some way or another. If there’s an alternative, that’s low-tech or manually made, they will keep doing it the old way, unless the gains are clear and enourmous with a software solution. Usually, they’re not. If the process were that innefficient they would already have been changed. None likes to risk profits 🙂

  11. Sage, sage advice. A couple of odd thoughts:

    Now consider the poor sap in the organization who is actually making do with the current software, who for whatever reason has not been brought into the planning process here. She’s the one who makes the process work now, but she’s always noting to the boss that the process is broken and works only with many hours of overtime — and so, because she is so overworked, management left her out of the planning process entirely (the better to let her get caught up, you know). She has one or two things that absolutely must be done, and no one else knows about them — she’s keeping the process going because she has created an Excel spreadsheet, can dump information into it and get it back to plug into the process. She’s just got an offer from another firm, and she’ll be giving notice in a few days . . .

    Second thought: I just finished a project with an educational institution, in the classroom. In that organization almost no changes, IT or otherwise, involve the classification that you outlined. In the war between pedagogy and IT, there is not even hope of getting the two sides to the peace table yet. Ouch.

  12. Julio: I particularly agree about making it hard to change things – without rigourous change management you’ll enter a world of pain.

    edarrell: I’ve just gone through the exact circumstance of of key users not being asked for their requirements. And from the sounds of it, I’m glad I’m not working in education.

  13. Francis

    Well for the consultant paid at an hourly rate working with clients who dumbly assume everthing is mandatory – is a financial (not morale) opportunity. A multitude of business cases exist where excessive feature building is accepted practice – by upper management of course.

    They are the prelude to excessive invoicing – the hall mark behaviour of the richest consultancies of Planet Earth.

  14. Yeah, the massive consultancies make their fortunes on this idiocy.

  15. Hey,

    I stumbled here as I was searching for meaningful ways to classify requirements by priority.

    I am currently dealing with a customer for whom everything is mandatory. So can totally relate to your post.

    Thanks for the information.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s