The Results are In! Analysis Skills’ Impact on Project Success-EN

In my last article (Wibbly Wobbly Business Analysis Skills Stuff), I talked about the analysis skills that are needed to make sure all the “stuff” is getting done on your project. In that post, I included a link to our “stuff” quiz and invited you to see how your team measured up.

Our quiz asked, “Here are 13 signs that “stuff” isn’t getting done on your projects….how many of these have happened to you?” The results are in….here’s what we found:

	Everybody agreed to the requirements, but blamed them at the end when something didn’t work the way they expected.
	The team constantly revisits decisions.
	You have “squeaky wheel” syndrome, where one or more strong personalities dominate discussions and decision.
	You have to chase your stakeholders down to get them to work on the project.
	You bought the package…but it doesn’t do exactly what you thought it would…
	You deliver exactly what the users asked for, but it doesn’t solve their problem.
	Everything works great unless the user makes a mistake or does something unexpected with the software.
	You get partway through the project, and have to back up because you discover another stakeholder.
	Users can’t get the reports or information they need.
	Something upstream or downstream blows up when you implement your project.
	You can’t make progress because you’re too busy dealing with change requests.
	It took so long to roll the solution out that it’s no longer needed or useful in its current form.
	It’s harder (or takes longer) for users to do their jobs after the solution is implemented.

I guess the good news is that lots of us have the same challenges. The bad news is that these challenges are affecting a majority of those who completed the survey. So what’s an analyst to do?

It’s tempting to start throwing around potential solutions. But then we’d be making the same mistake that lots of our stakeholders make.  You have to get to the root cause of the problem before you can propose solutions that will actually fix what’s broken. Otherwise you may simply mask some of the symptoms. Today I’ll share some thoughts about possible causes for our top two problems, and some tips for addressing them.

Project Problem #1: Blaming the (agreed-upon) Requirements

OK, listen closely with me here for a sec…listen…listen…

THUMP! Did you hear that?

That “thump” was the sound of your requirements being thrown under the bus.

Pretty frustrating, right? Everyone gives the requirements a thumbs up, but then immediately turns and points at them when something doesn’t go right. Why does this happen?

Possible Cause #1: They didn’t actually review the requirements.

Oops. If you think this may be what’s happening to you, here are some ideas:

• Consider your approach to requirements reviews. It’s really easy to attach some requirements to an email, send it off to the team, and ask them to provide you with feedback. Some people will actually read the requirements….some people won’t. If relying on independent reviews isn’t working, remember that there are several other review approaches. Alternate methods include document analysis, interviews, formal reviews, structured walk-throughs, prototyping, questionnaires, and even observation.

• Gauge your level of stakeholder engagement. You can have a great approach to your reviews, but if your stakeholders aren’t engaged, you’ll still struggle to get them to provide feedback.
  Check out our Stakeholder Engagement Quick Tips for some ideas.

• Think about how you’re “packaging” your requirements. “Packaging” refers to how you put information together for review. Make sure your stakeholders have everything they need – as an example, include supplementary materials like a glossary if it will help. Also consider how much you’re asking the stakeholders to review at any one point in time. Frequent small reviews are often more effective than infrequent “monster” review sessions.

Possible Cause #2: They didn’t understand the requirements.

You’ve got to know your audience. The audience will drive many things about your requirements including:

• Level of detail
• Formality
• Representation technique
• Delivery mechanism

We develop requirements in order to create a shared understanding. There’s no magic set of requirements templates that will do that. Carefully consider what you’re trying to represent, and to whom, and tailor your approach accordingly. Most of us tend to stick with representation techniques that we like, and with which we are comfortable. Like it or not, it’s not about you – it’s about your audience. Make sure you’re sharing information in a way that works for them.

Possible Cause #3: They didn’t really agree, but they didn’t want to speak up.

This problem is related to my next topic, which has to do with decision-making. It’s important to design a decision-making process that includes all the right people, and that gives everyone a chance to be heard in a penalty-free environment. Keep reading below for more on decision-making.

Possible Cause #4: There really was a mistake in the requirements.

Nobody’s perfect. Mistakes will happen, and sometimes we have to step up and accept responsibility for something that went wrong.

I’ve found peer reviews to be particularly helpful with this challenge. A fresh set of eyes will often spot things that we’ve overlooked.  The reviewer doesn’t have to be someone who’s familiar with your project. Even if they don’t know the business domain, another analyst can spot inconsistencies, gaps, and areas where our requirements just aren’t clear.

Project Problem #2: Decision “Swirl”

There are lots of reasons for revisiting a decision. Some reasons are justifiable – the business has changed, a risk has manifested itself, etc. Some reasons are less productive – somebody wasn’t paying attention the first time around, the wrong people were involved, and so forth.

Decision-making is tough. As analysts, we don’t generally get to make the decisions but we do need to be skilled at facilitating the decision-making process. Remember the three key components to decision-making:

1. Know who should make the decision. Some decisions can be made by a single individual. Others require a group. Make sure you include everyone you need, but nobody you don’t. If you miss someone, you’ll undoubtedly have to go back and revisit the decision. If you include people you don’t need, you’ll slow the process down and potentially skew the results. And those skewed results can cause the team to come back and revisit the decision at a later date.
2. Know how the decision will be made. In our class Facilitating a Requirements Workshop, students practice facilitating group decision-making. As part of this they are required to create a session plan that details exactly how they’re going to help the group reach a decision. If a student shows me a session plan that simply says “discuss the decision” or “talk about options”, I send them back to the drawing board. Exactly how will you help the team make the decision? Will you use a voting technique? Will you ask participants to present pros and cons? Will you elicit objective criteria and score the options? There are many techniques that can be used to help a team come to a decision. Throwing everyone into a room and asking them, “What do you all think we should do?” isn’t one that I recommend.
3. Know when the decision must be made. Timing can be everything. Remember that not all decisions need to be made right away. If you make a decision immediately, you may not have time to really think through all your options and evaluate them. If you delay the decision too long, you may not have enough time left to implement a more elaborate solution. So before you rush into scheduling a decision-making session, ask yourself…by when do we really need to have an answer to this question?

Our Decision Making Process Template is a great tool to utilize for your team to determine your decision path, decide on the decision making roles and keep track of the decisions made (or not made).

Remember to ask “Why?”

Keep in mind that what I’ve shared are possible causes for our top two project problems. Before you use any of the tips, be sure you know why this is happening on your project. Dust off your root cause analysis skills and get to the bottom of it. If you have other thoughts on why these problems occur, or how to address them when they do, I’d love to hear them! Leave a comment below and let me know what you think.

All the best,

Kathy