Software, Mockups, Requirements

I already wrote about understanding the big picture, but once you “get it” what do you exactly do with it? There is one particular thing that saved my life many times already. Develop a good summary of your requirements and leverage it immediately to maximize impact. It never fails if done correctly, so it pains me when I see some “fluff” taking the most important “space” in your documentation. Which is unfortunately quite often. So here is what should you do and how.

However you call this on your project (Management summary, Vision, you name it) those few paragraphs or a single page are developed with single goal in mind: to explicitly agree with customer’s boss on which exact problem (or problems) is being solved and how. You don’t want to get into situation where everybody seems to expect from you to solve each related problem along the way! Keep it short and to the point. Be sure to say what is NOT being solved by the project. For example you can say “Reporting won’t be done as part of this project”.

Once you have high quality draft, go to the customer’s boss and promise her you won’t need her to read anything ever again if she helps you to agree on those several paragraphs (it works every single time). What you will get is the short statement developed in fact by the boss (this is crucial!) of the people you are going to work with. Thus nobody will manipulate you in another direction: you can simply say “It’s a great idea, but let’s check what your boss wanted us to do…”.

Simple, isn’t it? And it gets even better.

You or (even better) your project manager should read this word by word on a kick-off meeting. And explicitly say the magical sentence: “This project won’t solve all the problems you may have, but it WILL solve those particular problems: …”. The point is that at this particular moment your customer and probably even his boss are standing there right beside you and nodding their heads meaningfully!

What you get is magically agreed upon scope project-wide – almost out of the box

Can’t tell you how often I see people jumping the gun and developing requirements for their software – right from the middle.

If you don’t take time to get (and write down) the big picture first, you are bound to get sidetracked more often than not. Which spells rework, rework, rework. What you need is the bird’s view of what needs to be done and for god’s sake WHY. So you will have the context and crucial guidelines for any later work. As project progresses, you will often have to choose among several legitimate but very different options. In such situations simply ask yourself “Which option brings us closest to original target in the big picture?”.

The caveat is that you as a humble operative can’t do this all by yourself. You need to be precise and to the point in aggressively getting your project manager to obtain what feedback is needed to solve the puzzle. Nothing good will come from “I’m doing my job and other people should do theirs”.

But still you need to know how to moderate interviews and workshops with wildly different personalities. So… the trick here is to be the top communicator! Always improve on this: not only you’ll get meaningful requirements faster but hey – good communication skills are groundwork for more success in almost all areas in life