For some, there is no clear line between religion and managing software projects. Our recent post and ranking poll on the 12 reasons software projects fail yielded some spirited input and results.
The winner—the top-ranked, number one, most challenging bugaboo of them all:
Defining Software Requirements.
What it is…
Defining software requirements is the art, science, and skill of discovering and translating what the internal or external client (or customer, member, etc.) wants and needs so that software engineers can understand it—and create software that meets or exceeds their expectations. This is typically done by a Business Analyst (BA), Product Manager, or anyone who can effectively translate the vision of the client to those doing the development.
Why it’s important…
This might be (should be?) obvious, but like building a house, the construction experts need to know what you want in order to make you happy with your new digs.
A better analogy might be ordering a sandwich at Subway, where there is a quick, agile back-and-forth cadence of communication while the work is being done, with adjustments made and ingredients added until your order is complete: just the way you like it.
Common mistakes and tips on how to avoid them…
Whether building a house, a made-to-order sandwich, or breakthrough software that transforms your company, communication is the key to success. With input from nearly 30 software professionals, here are the most common mistakes made when defining requirements and how to avoid them:
Mistake #1: Not assembling a team with representation from all appropriate stakeholders. This mistake leads to incomplete or inaccurate information influencing the quality of the requirements, and it results in a sub-par product.
How to get it right: Invest the time, money, and political capital to get the support of an influential leader and committed participation from the right people on your project team. Be sure your developers get first-hand information often and can enjoy the benefits of seeing the results of their work. No one likes bowling through a curtain.
Mistake #2: Skipping or shortcutting the current-state assessment and starting design and coding too soon.
How to get it right: Take time to understand the business objective, the business process(es) to reach that objective, and how the software will enable the process(es).
If there are more than a couple of actors and systems who interact with the software, you will likely benefit greatly from a facilitated workflow process modeling-and-mapping exercise.
This will reveal opportunities to improve and simplify the process and will show clients what is possible. Remember, we often don’t know what we want until we know what is available.
Mistake #3: Taking too much time and diving too deep into the details to define and document every requirement of the software before getting started.
How to get it right: After gaining important context in your mapping-and-modeling session, your project team should use an agile approach to define a minimum viable product (MVP)—and then get started.
Mistake #4: Not handling change requests properly.
How to get it right: Be sure your MVP is well-defined and everyone is clear and in agreement on what will be delivered and when. If this should change (shock of shocks, right?), then communication skills and the ability to deftly negotiate priorities are critical.
Again, your process for prioritizing the work is very important here and the project team must honor that process as priorities change, as they inevitably will.
Mistake #5: Not using requirement-gathering and prioritization tools and techniques correctly.
How to get it right: Should your stakeholders write user stories or should the BA write use cases? Is a MoSCoW prioritization tool best, or would an effort/impact matrix work better? Or perhaps a feature/function multi-voting approach?
The answer, as usual, is that it depends. It’s more than we have room for in this post, but it’s important to point out that this is part of a skill set required of the facilitator. Whether they’re called business analyst, project lead, product manager or something else, they must know the tools available and have the situational awareness to know when to use them.
It helps if they are not a purist in any single methodology and can pull from a large toolbox and depth of experience to navigate the team to a successful MVP (and through subsequent iterations).
Want to know your project success odds? Find out with our quick and easy project risk assessment here!
Need to chat with someone about your software project? Contact us.