Large software projects still a gamble

There have been numerous famous examples of large software projects over-running budgets and schedules in dramatic fashion.  A great article on this topic was published in IEEE Spectrum in 2005 by Robert N. Charette, which includes a short list of such notable failures.

A recent study confirms that IT projects remain a gamble with odds of one in six that a large IT project will go over budget in a big way – 200% on average.  Read the article here.

---

O Requirements Champion, Where Art Thou?

In my previous article (http://www.batimes.com/articles/are-we-there-yet.html), I referenced the Standish Group’s CHAOS Report, which stated that the biggest issue leading to project pain is lack of user input.  Anyone reading this blog should know that user participation is a vital part in the software development lifecycle (SDLC).  Therefore, you should interview the customer for requirements early and as often as possible in the SDLC.  Since you can’t get input from every user, you will need to place users into groups which are based on the features and functions they most utilize.  These groups are called user classes.  Each of these user classes will have its own prioritized set of user, functional, and non-functional requirements.  Once you have identified the different user classes, you will need to name the product champion within each user class.  This is a person who has expert understanding and decision-making power to formulate requirements on behalf of the user class they are representing. Even if you can locate this spokesperson, they will have other tasks in their day-to-day life that will compete with the time you need to spend with them.  For this reason, you should make a request to the champion’s management, that their involvement is a priority.

Since most projects have several user classes and each person knows something different from the other, you will need a small number of these product champions.  During requirements elicitation, each of these champions will get involved often and at different times depending on the function/feature/process being detailed.  You should look for one representative per user class, and sometimes you can get lucky by finding someone who can represent several user classes.  This product champion should be able to communicate requirements, suggest ideas, reconcile between contradictory information, and help you arrive at a cohesive set of requirements for their user class.  This person also needs to make key decisions, which means they need to be informed, respected, and be an effective communicator within their user class.  In a model situation, the product champions are located with the analysts, testers and developers, and they can devote their entire time to answering questions and providing all the details during requirements elicitation.  In reality, few champions are located with the analysts, testers and developers.  Also, you are fortunate if you can get a couple of hours a day of the champion’s time due to other tasks they need to perform within the organization.  Therefore, when selecting project champions, look for the following traits and factors:

• Knowledgeable and respected within their user class
• Understands and is committed to their tasks as a product champion
• Has the time to commit and their management encourages their involvement
• Has the power to make key decisions.  If the product champion does not have the power or the willingness to make the necessary decisions, then the developers will make it for them.  

This is not a good idea because developers usually do not have the right point of view to make the best decisions for the business.

There are situations where the analyst has very little or no access to the real users.  This happens quite a bit when developing commercial software products for a new or emerging market.  This is where you need to use surrogate users versus real user champions.  This can be a product manager or a subject matter expert (SME) in the field.  There are a couple of groups to stay away from if you are going to choose surrogate users.  Avoid the manager of the real users as a surrogate champion.  Usually, managers don’t use the product like the real users use the product.  Secondly, managers don’t have the time to fully dedicate themselves during requirements elicitation.  Another group to avoid as a surrogate champion is the software developer.  Unless the developers themselves are using the product, they do not make good surrogates because developers have a different point of view of the product from the actual users.

If your stakeholders do not put priority on allowing product champions to work with the analysts, then tell them this: you’re going to need to get the user input now if you want to spend less time, money, and frustrations during user acceptance testing.  Your projects will be less “challenged” when you get user input early on and often during requirements elicitation versus waiting until the system is in testing or in production.  If the stakeholders can’t get users or surrogates during requirements elicitation, then this indicates that there is little assurance to the success of your project.

---

Requirements: Express Yourself.

Requirements describe characteristics of something that doesn’t yet exist.  They can help people ‘imagine’ the future product.  For example, if the requirements are for an office building they help us imagine this “physical product” that one day you’ll be able to walk through, view from different vantage points, touch it’s bricks, and knock on the doors.  Software applications on the other hand are ‘conceptual’ or ‘imaginary’ products instead of physical.  You can’t hold them in your hand and feel the weight or throw them across the room (although many wish they could).  So in the case of software products, their requirements ‘imagine’ something that is ‘imaginary’.  It’s no wonder creating good requirements and communicating them effectively is tough.  As businesses continue to reduce their dependence on ‘bricks & mortar’ and increase their dependence on ‘applications’ for their success, we simply must do a much better job with software requirements.  A key factor in determining the effectiveness of your requirements lies in how you choose to express them.

The first dimension:First Dimension

The most basic form of requirement is the declarative text statement.  “The building shall have ten floors.” You read it left to right (or speak it), one word after the other.  It’s a single, continuous stream of information. The author takes their thoughts, encodes them into characters that comprise words, and hopes that the reader when decoding these words receives the identical thought intact.  I’d refer to this form as being one-dimensional, and not terribly “expressive”.  A lot of people still use only text and no other form to express the requirements for their software applications. 

The second dimension:Second Dimension

A picture’s worth a thousand words and in the case of buildings you inevitably also use two-dimensional drawings, commonly referred to as blueprints.  In fact, for any building that requires a government permit - pretty much anything bigger than a dog-house - it’s often a legal requirement to have blueprints.  A very large percentage of those who define software applications also use two-dimensional drawings and sketches to describe what they need built.  Some of these drawings adhere to standard principles and rules while others are ‘home-grown’ and have meaning only to those in the same company, department, or project.  Regardless, using diagrams tends to be far more expressive than using text-only, helping people expose errors in the requirements early and improve communication.

The third dimension:Third Dimension

In the case of buildings, especially the larger they get, it’s very common to create a scale model.  This is a miniature version of the real thing and because it’s a ‘model’ it is, by definition, incomplete.  Not every last little detail of the real building is put into the model (like the window coverings, wall trim, electrical wiring, for example).  These models really take it to the next level in helping people ‘imagine’ the future building and are tremendous aid to communication about the future product.  In the case of software applications you can have models too and when done properly they can have a similar beneficial effect.  The most popular type model for functional software requirements is perhaps the Use Case Model.  Structured models using techniques like data flow diagramming to help express requirements became popular in the 1980’s and are still being used today.

The fourth dimension:

We’re a long way from simple declarative text statements now, but there’s yet another even more expressive ‘dimension’.  You can move the modelsFourth Dimension through ‘time’ while exposing them to the kind of environmental conditions they’ll experience when built. This is called a simulation.  Simulation can expose a whole new set of issues that you never would have noticed otherwise.  In the building industry, this was learned the hard way from several very famous structural ‘failures’ - very much like we’re now learning the hard way in the software industry.   Requirements tools that exist now allow you to simulate your software requirements – letting them move through ‘time’ while responding to user and external inputs, showing how the future application will behave.  And like with building simulations, software requirement simulations help expose a whole new set of issues that you may never have noticed otherwise.

Creating and communicating software requirements is difficult because we’re dealing with something ‘imagined’ and hoping that everyone involved is imagining the same thing.  The only way to align these visions is through effective communication which can be achieved with stronger forms of expression.

---

Requirements, Grandma, & Apple Pie.

Today I was dragged into yet another debate between two co-workers on whether something was a requirement or design.  Before that topic could be put to bed, the discussion took a right turn into whether the requirements were complete and sufficiently detailed.  My earliest recollection of this exact same discussion was at my very first job out of college;  it’s taken place countless times since then, and here I am (many) years later watching two people go through it - yet again.

Typically we’d go drag out the definition of a ‘requirement’ seeking enlightenment.  Off to the “tablets” – the IEEE definition, and definitions from any number of prominent textbooks on the subject.  But hang on – whenever you go about building anything you need to have some requirements.  Even if they’re only spoken, or just in your head, you still need requirements.   And we’ve been building things for a whole lot longer than there’s been an IEEE and long before any of those books were written.  So a hundred or two hundred years ago if I asked “what is a requirement” what would the answer have been?  Until I have the time to go research that, I’ll just rely on my time-tested method for getting answers ... what would Grandma say?

Scene:  Grandma’s kitchen years ago

Grandma has invited some people over for dinner and decides to bake an apple pie but discovers she’s missing a few ingredients.  She decides to have me, a young boy at the time, ride my bike to the store to get them – a small bottle of cinnamon, a pint of cider vinegar, and a pound of sugar.  She hands me some money and tells me not to make any side-trips since she wants the pie made in plenty of time before dinner.  Knowing how easy I can head off on tangents (caused by things ranging from a turtle crossing the road to noticing the store-keeper’s daughter Donna), she writes all this down on a list and hands it to me.

Grandma made a series of decisions:  she decided to have some guests over, she decided bake a pie, decided to have me go to the store, decided I should take my bike, decided I should get cinnamon, cider vinegar, and sugar, decided I should pay for it with the money she provided, and decided I need to go directly to the store and back.  Before this mission is complete there are several more decisions needed but Grandma didn’t make them.  Exactly which route I should take (there were three routes basically of equal distance)? Should I take the same route there and back?  Which specific brands of these items should I buy?  Which cashier should I use?  Does Grandma want them in a box, paper bag, or a plastic bag?

When you boil it down, getting something done whether it’s baking a pie or building a software application requires a series of decisions.   Somebody makes a decision, and others act on it.  For those who act on the decision, they see the decision as a 'requirement'.

Another way to look at it is that there’s no such thing as requirements or design, so we should stop wasting our time debating it.  They’re all just “decisions” made by various people along the way, each decision aligned with the previous but getting progressively more detailed.   I first heard this point of view from Alistair Cockburn in a Requirements.net podcast which I highly recommend you download and listen to.

Of all the decisions that Grandma made that day, not all were “requirements” for me.  Her decision to have guests over wasn’t my requirement.  I wasn’t even aware of some of her decisions, like the one to bake the pie at 350F.  This wasn’t my requirement either.  But many of them were, like these:

• Use bike to get to and from the store
• Get bottle of cinnamon, pint of cider vinegar, pound of sugar
• Pay using money Grandma gave me
• No side trips

But what about all those decisions Grandma didn’t make that I need answers to, like the route to take and boxes vs. bags?  Are my requirements incomplete?  Are they not detailed enough?   The answer to this is “maybe”.  It is possible that Grandma was absolutely correct in the set of requirements she had given me, and that it was her intention to leave all the remaining decisions up to me, trusting my judgment.  From Grandma’s perspective the requirements she provided were complete and sufficiently detailed (we’ll call this the “I don’t care about the details, just get me my stuff” scenario).  On the other hand, it’s possible that Grandma did care about the details but was in such a tizzy about these guests coming over she simply didn’t think things totally through.  In this case my requirements were not complete and, unless by some miracle I make the exact choices Grandma would have made, things won’t be pretty when I get back (we’ll call this the “cider hits the fan” scenario).

The journey of building something involves a long series of connected “decisions”.  Your process should describe when the decisions need to be made and who (or what group) makes them.  Consider the set of decisions found in a Requirements document for a software application.  Generally, this set of decisions is made by the client – hopefully leveraging the services of a Business Analyst - and they need to be acted on by the developers, testers, and others involved in delivery of the solution.  As for when these decisions are made, as mentioned this depends on your process.   In a traditional waterfall-style project these decisions are made early – around the 25% mark in the planned project duration.  The classic pitfall is that waterfall-style processes often prescribe that these decisions must be made at an early point even if we lack information on which to base them.  Not surprisingly some percentage of the decisions end up being wrong and the project suffers large amounts of unplanned rework.  More modern agile approaches are based on the assumption that you don’t know everything at this early stage so the decisions are made incrementally along the way as you acquire valuable knowledge from building and testing “portions” of the system.

So where does the Business Analyst fit in?  They play a critical role in helping to prevent the cider from hitting the fan.  Their skills in analysis and facilitation help the client (Grandma) make the right decisions and clearly communicate them so that she gets what she needs to solve her business problem (impressing her guests with an amazing apple pie in time for dinner without going broke).  Skill-full questioning and brainstorming discovers if Grandma does in fact care about some of the details she’s overlooked (she hates plastic bags), validates her requests (sugar now comes in smaller sizes so does she really need 1 lb.?), and explores the risks and their mitigations (if you see Martha “coupon-queen” Smith in the express line, head to a different checkout).  As part of their job the Business Analyst recognizes and leverages the skills of the stakeholders like Grandma’s expertise in pie-making and check-out selection, and my expertise in high speed bike-riding while avoiding traffic - and Donna.

Try to avoid getting wrapped around the axel debating the line between a requirement and design.  From what I’ve seen these debates really only happen around a small percentage of the “decisions”, but can be very distracting.  Instead, focus on who should be making the “decision”(who has the expertise to make it, who has the ‘right’ to make it, who is impacted by it) and if this is the right time to make the decision (are other urgent decisions depending on it, do we have enough information to make it).

---