Requirements

It will almost always cost more to fix a requirements problem during the execution phase than if the same problem was discovered in the planning phase. And the root cause of these problems is usually people-oriented. Here are four key best practices for writing better project requirements.

It is important to define your project’s technical architecture early in the process, with input from the team. This includes all the hardware, software and other technologies your project requires. It will need to be flexible, but the sooner you get it right, the better off your budget and schedule will be.

Adult children. Jumbo shrimp. Seriously funny. I’m sure you recognize these expressions as oxymorons — self-contradictory phrases, often with an ironic meaning. Should we add “agile requirements” to the list? Does agile development fit in with traditional requirements practices? And if so, how?

In an Agile project, you don’t create large documents to hold user requirements; in fact, you don’t need a traditional document at all. The preferred technique is to use a product backlog, which represents a prioritized collection of work remaining on the project at any given time.

In the summer of 1940, with Germany winning the war in Europe and Japan rising in Asia, the U.S. Army initiated a procurement of a revolutionary vehicle prototype that would help win World War II and endure for 70 years — a project which has lessons to teach us today.

To answer the question, we need more than cost, schedule and requirements. We need a set of capabilities that are agreed upon, and tangible evidence that they have been delivered. In Part 2 of a series, we show how to go about discovering the capabilities needed for project success.

In his latest course, an experienced project management trainer makes the case for a durable but resilient schedule model that accounts for requirements, dependencies and uncertainties as fully as possible.

Agile projects benefit from the rapid pace of feedback achieved through frequent releases, but what happens when you’re working on a complex project with a long timeline and resistance to releasing early? As a compensating strategy, story maps based on project goals can leverage some benefits of a release even if you aren’t “going live” any time soon.

Every project runs the risk of scope creep, but not all scope creep should be prevented if it leads to enhancements that the customer needs. The key is how you document and manage it. Here are some suggestions for keeping your project on track, and adapting to stakeholder needs.

It is not in the best interest of an organization for either project managers or business analysts involved in defining business needs. They need to be focused on delivery of the solution and ensuring that it meets the business need. And they do that best when they are neutral facilitators, now owners of the project.