Prepare yourself, this one is a doozy.
In a world where software projects commonly suffer from poor requirements, the very idea that a project team can "overthink" requirements sounds absurd. Hey, if it didn't happen would I be writing about it? Very interesting projects with very well-intentioned aspirations have outright failed because it never even got off the ground.
The proper term for this is analysis paralysis, a state in which a project suffers because the planning and requirements elicitation phase is more expensive than the benefit that is derived. This might be because planning takes too long and the opportunity for the project has passed, the personnel cost of the requirements phase exceeds the budget allowed, or some team members are under-utilized waiting for the planning activities to finish.
In the 'real world', what does analysis paralysis look like? Let's see if this scenario rings a bell. So someone super important greenlights project X and the subject matter experts are organized into a team. A 'first' meeting is planned, but the most important planning team members (i.e., the really good ones) are busy because they are wanted in a million other places. Important people are in demand! They decline the meeting and thus, it is rescheduled for a few days later. Planning is a little behind schedule now, but nothing that can't be made up through diligence and hard work.
Eventually, the 'first' meeting actually takes place (yay!) and half of the meeting is spent reviewing some document everyone was supposed to have read before they showed up (boo!). The second half is spent producing results and the citizens rejoice. That said, one important team member, let's call him bigwig A, can't show up because he's really, really busy. Some crises at some client site caused some horrible failure that required his full attention. While everyone else is warm and fuzzy because the team is making progress, bigwig A finally gets around reviewing what was accomplished and identifies all sorts of issues. The 'first' meeting is then held again, rehashing what went wrong in the first...er…I mean second 'first' meeting.
So yeah, I'm sure all sorts of bells are going off. This project is already thrashing and if the trend isn't drastically improved, the project will be paralyzed. So how does this affliction come about? It usually comes in one of two ways, each of which sends a cold chill up my spine.
The first is common in smaller organizations. Most projects have poorly understood requirements. A few of these types of projects demoralize good teams and leadership swears it will never happen again in order to prevent a mutiny. They place a lot of emphasis on the planning process and project managers say absurd things like "My team won't start until we have all of the requirements!" I live in a glass house, so don't worry about the flying rocks. Anyways, now everybody that's anybody is now required to fully participate in some elaborate planning process (in addition to all of their other responsibilities), and the nightmare begins.
The second is common in larger organizations where projects have inter-organizational dependencies. Management and teams are set up in a matrix, and teams are expected to provide resources and expertise to other teams that have specific needs. Some large software project comes along that is being managed by team A, and some manager in team B is asked to provide a resource to help team A. Said manager looks over his roster and identifies a really good resource that will do a great job. But wait! That resource is needed to satisfy team A's responsibilities. After all, he or she is really good at what they do, and team B simply cannot afford to lose them Another resource is selected instead, one team B can live without, and that resource doesn't have the expertise, capability, and maybe even time to provide team A with quality help. Planning starts, team A realizes they have the wrong resource and they have more work to make up for the poor help they've received from team B, and the nightmare begins.
Some champion the idea that bureaucracy is to blame for analysis paralysis, but I think that's just a cover for the real catalyst: poor leadership. Now let me qualify by saying poor leadership can be blamed for all the evil in the world. It's an easy target that makes the masses happy. So we throw more process and more bureaucracy down to cover for this poor leadership, and we find ourselves in a situation where we blame the bureaucracy instead of the reasons that bureaucracy blocks our way.
So how do we prevent analysis paralysis? Do a better job of leading our projects! But that copout isn't enough, so let's concentrate on three major components that can help your project team avoid analysis paralysis.
-
First, you must manage the resources involved in project planning. Major projects usually require a large number of people to be involved in the planning process, and many of those resources are not owned by the team responsible for leading the project. This situation is precarious because a resource whose time you don't own is a resource you probably don't have. It’s impossible to have the full attention of all necessary resources, so the person managing the requirements phase of the project must clearly communicate the expectations of how these individuals will be involved and, most importantly, there must be real consequences if any resources are not providing adequate value. This can mean different things in different organizations and you can figure out the details.
Even the smartest, most well-intentioned people can be very busy and their priorities may not be in line with yours, so it isn't necessarily only a matter of battling incompetence. It's just that a resource that is unavailable or distracted is no better than a resource that is outright incompetent. In either case, you aren't getting what you need.
-
Second, someone must lead the planning and requirements elicitation process. Managing the requirements phase and leading the requirements phase are two different things. Managers simply have to handle logistics, track progress, and make adjustments if the project is off track. But some measure of quality must be met, so someone who truly understands what needs to be built should lead planning and elicitation activities.
This person needs to be capable of making hard decisions and mediating conflict. People will have different opinions on what types of things are important in a project and how those things should defined, and many times they will have strong opinions. I'm of the opinion that this type of disagreement can be a good thing for a project, as the end result is usually strengthened by this haggling. In fact, you should probably be worried if this isn't the case, or at least get rid of the redundant resources. You need different points of view, not several people with the same point of view.
A strong leader will foster this type of discussion while making sure the team stays on task. A strong leader will also be able to make a sound, well-reasoned decision if a conflict does not resolve itself in order to move the process forward. Without a strong leader, teams get bogged down and their schedule slips, and this is the first sign of numbness.
-
My last recommendation is my most specific: teams should employ a Scrum-like model to managing requirements. I've participated in a Scrum project from end-to-end, and some I'm not exactly the biggest Scrum fan in the world (a topic for another day). That said, the model Scrum uses to manage requirements is genius. It is simple, effective, and really hard to screw up if you follow the rules.
In Scrum, requirements are kept in a list, called the product backlog. The product backlog lists the requirements with the most important at the top and the least important at the bottom. Each requirement has some weight, being the resource cost expected to implement that requirement. Before each project iteration, take the requirements from the top of the list and drop them into your iteration until you have consumed all of the available resources in that iteration. It’s just like shopping. Things have a cost and you have only so much money, so you have to be selective about what you buy so that your money is well spent.
The hard and fast rule in a Scrum project is that once a requirement finds its way into an iteration, it should not change. If it needs to change, that change should be dropped on the product backlog as a new requirement and managed as such. The requirements team, or anyone in the organization for that matter, can add requirements to the product backlog at any time. However, only project principals should be able to prioritize the product backlog, and this prioritization should take place before the beginning of each iteration.
To manage requirements using the same model that Scrum employs, you must be develop your software using fixed-length iterations and you must right-size requirements so that they are always smaller than the total resource allotment for an iteration. That's it.
How does this prevent analysis paralysis? I'm glad I asked.
Managing requirements in a product backlog prevents analysis paralysis by creating a situation where the design and construction phases of a project can move forward before requirements elicitation is complete. The most important components of a software project are the easiest to identify and define. It's the peripheral components that tend to send a project on a tangent. Once enough work has been identified to cover an iteration, the development team can cut loose.
The Scrum requirements management model keeps the requirements and planning teams, and all stakeholders really, involved in the project from start to finish. The waterfall model of requirements gathering that so many organizations insist upon will be gone and you will now have a project that is effectively agile, in that it can effectively accommodate change
That's enough of a drubbing for one post, so I'll conclude things there. Just know that how one manages the requirements and planning phase of a project is critically important to the success of a project. I wouldn't prattle on about it if I didn't think so. If you want to learn a little more about scrum then you can find a lot of great sources out on the great interweb. To keep this relevant to Team System, there are a couple of Scrum-based process templates available:
-
Conchango Scrum Template - I've worked on a project that employed the Conchango template and while there were a few things I didn't like, they were a lot more about Scrum than about the Conchango template. One warning, the process guidance teaches you a lot more about Scrum than it does about the process template that is provided.
-
Microsoft eScrum Template - I haven't taken a look at this Microsoft-provided template yet but I have heard good things from people who know what they are talking about. I'll take a look soon and give my thoughts in this space.