When it comes to requirements, reinventing the wheel is costly, time-consuming and often unnecessary. The latest evolution of Jama’s collaborative requirements management platform introduces an intelligent, enterprise-wide system to reuse the requirements and other product details that are the same across multiple products.
Poor request management will get your project off to a bad start from which it may never recover. Here are four recurring request management issues that derail project, program and portfolio effectiveness, from the gathering to prioritizing and tracking of them. How many sound familiar?
The sometimes dysfunctional relationship between project managers and business analysts can be compared to that of the two main characters in the popular book-movie. Without strong PM-BA collaboration, projects can fall prey to competing perspectives. Here are six strategies to find common ground and make the relationship work.
Most would say it is a project’s team members, not the project manager, who create a quality product. They believe that quality means doing quality work, or, that it can be tested in. But, in fact, the project manager has a lot to contribute towards a quality product, starting with the schedule and communication.
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.
"I do not know anyone who has got to the top without hard work. That is the recipe. It will not always get you to the top, but should get you pretty near."