Making Good Project Decisions – Part 2

In Part 1, we discussed the first three of seven general questions that you can ask yourself and review with your team when making significant decisions on your projects.  In Part 2, we’ll continue down this path and examine four additional questions to consider as part of your overall decision-making process in your efforts to make the best possible decisions for your project, your team, and your customer.

What is the window of opportunity?

If the building is on fire, no matter how complex choosing your route of escape might be, there is only a set amount of time that your decision will matter. If you wait too long to make the decision, it will be made for you; routes will close and all options will go away eventually. The way the universe works is that big decisions don’t necessarily come with greater amounts of time to make them. Sometimes, you have to make tough strategic decisions quickly because of the limited window of opportunity you have. And sometimes, the speed of making a decision is more important than the quality of the decision itself.

Have we made this kind of decision before?

There is no shame in admitting ignorance: it generally takes courage to do so. If you’re working on anything difficult or cutting edge, there will be times when you have no idea how to do something. Don’t hide this (unless you’re choosing speed over quality for the decision in question), or let anyone else hide it. Instead, identify that you think the team, or yourself, is inexperienced with this kind of choice and might need outside help, or more time, to think through the problem. If a leader or manager admits to ignorance, she makes it OK for everyone else in the room to do the same. Suddenly, decision making for the entire team will improve dramatically because people are finally being honest.

Read more »

Ten Characteristics of Successful Project Teams – Part 4

In Part 3 of this series we examined item five of ten characteristics of successful project teams: balanced participation.  Here is the full list of the ten main characteristics of successful project teams that we will be examining in this series:

• Clearly defined goals
• Clearly defined roles
• Open and clear communication
• Effective decision making
• Balanced participation
• Valued diversity
• Managed conflict
• Positive atmosphere
• Cooperative relationships
• Participative leadership

For Part 4 of this series, we’ll examine items six and seven above in more detail: valued diversity and managed conflict.

Valued diversity

Valued diversity is at the heart of building a team. Thus, the box is at the center of the model. It means, put simply, that team members are valued for the unique contributions that they bring to the team.

Read more »

Four Characteristics of a Good Requirement

The quality of your requirements can make or break your project.  Good requirements give you control over your project development and prevent rework. Less rework means your project has a much better chance at on time and on budget delivery.  All that adds up to project success and high customer satisfaction.

What makes a requirement a good requirement?  Good requirements generally meet four basic criteria:

• Good requirements meet a specific need
• Good requirements are verifiable
• Good requirements are attainable
• Good requirements are clear

Let’s look at each of these in more detail…

Meeting a specific need

A requirement is a basically a statement of something someone needs.  The something is a product or solution that performs a service or function.  The someone may be a company, a user, a customer, support, testers, or another product.

For example, a company needs a manufacturing machine that stamps out widgets, or they need a certain plastic to feed a manufacturing machine that they already have.  A bank must process debit card transactions.  Alternatively, a requirement is a statement of a characteristic of something someone needs.  Proceeding with these examples then, a machine must stamp out 60 widgets an hour.  The raw material must be formed in sheets, or it must be red in color.  A bank must process at least 1,200 debit card transactions in one hour.

Read more »

Final Thoughts on Requirement Prioritization

Your first priority in the requirement prioritization may be selling the stakeholders on the concept of prioritizing requirements before design start.  This isn’t an easy task.  As we discussed, a customer stakeholder is likely to react with the notion that you’re actually trying to eliminate requirements.  You have to convince them that this is not the case.

Once the stakeholders agree to prioritizing requirements, you will guide the stakeholders through the prioritization process.  Then, you will incorporate the results into the project or the product development schedules and budgets.  You must enforce the priorities throughout the development process.

As development progresses, you will identify situations that trigger use of the priorities.  These situations may include: impending resource shortages, changes in external constraints or expectations, and conflicts.  You must ensure that the priorities rule the outcome.

Requirement prioritization early in development helps a manager control project risk and change.  Knowing requirement priorities focuses a product or project development team and guides intelligent choices for phasing in product features over time.  It prevents the “bailing” that so often occurs just before delivery, in which partially implemented requirements are thrown overboard in a frantic effort to save dwindling resources for finishing the critical components.  Above all, it’s one more communication channel between customers and developers.

Read more »

How Do You Go About Prioritizing Requirements?

Whether you are on the customer side managing requirements or on the delivery side managing the development of the solution or product, you need a simple method for realizing the benefits of prioritizing requirements.  Formal prioritization methods do actually exist, but most projects don’t really need an investment in a formal process.  Sometimes a mindmapping tool like Seavus DropMind can prove beneficial, but it depends on the project and how much definition has already gone into the requirements at this point. The benefits of prioritization have to exceed the cost of actually doing it.  Large complex projects may prove a formal process to be beneficial, but for the purposes of this article, I won’t go into that depth or make that assumption.

Most projects can enjoy the benefits of requirement prioritization by following a simple five-step process:

1. Define priority classes
2. Classify the requirements
3. Resolve the differences
4. Create priority-based development schedules
5. Maintain the priorities

I will expand on each of these….

Define Priority Classes

Keep them simple.  A numbering system of 1-2-3 works very well.  Number the essential, non-negotiable, and urgent requirements with priority 1.  Assign priority 2 to the useful, negotiable, or slightly deferrable requirements.  Save priority 3 for merely desirable, flexible, or “someday” requirements.  Educate all stakeholders – internal and external, customers and developers – on the prioritization scheme.

Read more »