Why is it So Hard to Plan Well Up Front? – Part 2

In Part 1 we looked at the problem with up front planning and requirements definition and the first of three key American cultural tendencies that can contribute to this problem … impatience with time.

In this Part 2, we’ll look at two more cultural issues – the acceptance of mistakes and the urge to improvise.

Acceptance of Mistakes

America has often been called the land of comeback opportunities.  Everyone gets a second, third, fourth, fifth chance and so on chance.  In the US, we tend to forget the trials and tribulations of the process and focus only on the end result, saying “Because it worked out okay, there’s nothing to learn.”  In fact, we admire comebacks more than people who never failed in the first place.  We honor them.  We are more loyal to a supplier who quickly fixes a mistake he makes than we are to a supplier who never makes a mistake.

Most people in project and product development assume that mistakes are inevitable.  Some mistakes are.  However, we often confuse preventable mistakes with inevitable ones.  Poor preparation and inadequate understanding of customer requirements result in what I’m referring to as preventable mistakes.  There’s really no honor in scrambling at the last minute and running over budget to get out a solution to a customer when it could have been prevented up front with better planning.

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 »

Should Requirement Quality be Measured?

Measuring requirement quality can reveal opportunities for long-term improvements in requirement definition, can show you where to invest for improvements, and can help you develop your team.

Opportunities for improvement

If requirement quality isn’t measured, there will be no future improvement in requirements. Every project – in terms of requirements quality – will be a rerun of the last project. No lessons learned. No forward progression.

Did your last project have rework? Were there any crisis situations in testing? Were there customer complaints? A review of the last project’s requirements may show you how to avoid some of those same headaches on your current and future projects. Read more »

Onboarding with Success

When you’re asked to jump on a new project how do you go about doing that to ensure your best chance for success? That may often depend on why you’re being asked to take over the project … and it can be for any one of the following reasons:

• Previous project manager failed to manage the team and project effectively
• Previous project manager lost the customer’s confidence
• Previous project manager lacked the expertise to lead the project based on new direction
• An emergency necessitated an early departure for the project manager
• Co-management became a necessity due to changes on the project Read more »

Scoping the Project for Better Requirements

Good scope before requirements

The earlier you define scope, the more efficient your requirement definition process will be. Work done before scope definition is usually wasted effort. An early scope definition keeps requirements writers from diverging, reduces requirement inconsistencies, and keeps the big picture in view. It also shortens the time required for requirement writing and rewriting and reduces debates.

If you do not give everyone writing or reviewing requirements your scope definition, they are likely to create their own. Imagine listening to a movie without watching it – as I have done many times on trips in the SUV listening to a movie several times but never seeing it as it’s playing in the DVD player behind my head. I have a vision – my own vision – of what’s going on and what the characters look like and what the set looks like, but if no one describes it to me in detail or I don’t see it for myself then that’s all it is … my own vision. And it likely differs greatly from the actual film itself. Read more »