Viewing Posts by Marian Haus
The Scoop on Requirements Scoping
| We've all been there. When a project's scope isn't properly managed, it can lead to schedule delays, budget overruns or not meeting project goals. Requirements scoping can help keep projects under control by establishing what criteria — such as prioritization — will drive decisions. The process also clearly details what the project will deliver, and perhaps just as importantly, what it won't. Depending on a project's complexity, goals and project management approaches, there are various ways to manage requirements scoping. Here are three of the most common. 1. Early scoping assumes all scoping is done as part of the project charter or during the scope definition. The approach relies on precise estimations of required resources, budget and time. It discourages scope creep and requirements changes. The advantage of early scoping is that it facilitates starting project work ahead of time. On the other hand, poorly estimated efforts can translate into budget or schedule overruns, resources bottlenecks or missed project goals. Early scoping is recommended for projects where the main focus is on the scope, and on ones with no, or minimal, budget and schedule constraints. For example, early scoping works well on consolidation or integration projects, where the constraints on the scope (budget limitations, for instance) impact objectives. 2. Late scoping is performed after collecting, analyzing and even designing the requirements. At such late stages, efforts estimates are much easier to assess and generally more accurate. Although late scoping can keep a project within budget and schedule boundaries, this approach has a considerable downside: Efforts spent for out-of-scope requirements are wasted or deferred. Consequently, this leaves less time, budget and resources for addressing in-scope requirements — the ones that matter. Late scoping is recommended for projects addressing requirements that have similar (and not critical) relevance for the project's outcome — for example, regular maintenance projects. 3. Iterative scoping is a balanced, incremental approach. The entire scope is broken down and prioritized by items that have the highest relevance. These will be addressed in the first scoping round. The rest of the requirements, as well as potential changes or rework, are subject to scoping in subsequent iterations. The requirements scoping and the project work advance in a rolling wave approach. Iterative scoping is especially useful for IT and agile projects. How do you manage requirements scoping on your projects? |
Gather More Than Just Requirements
Categories:
Project Planning
Categories: Project Planning
| When managing requirements, we naturally focus primarily on the business need or opportunity the requirements will address. We pay attention to how requirements are formulated, and whether they are clear, comprehensive and aligned to the project goals. There's nothing wrong with focusing on the "what" of requirements — that is, what is asked to be delivered. But to avoid any major problems during the project, it's also important to identify the related assumptions, constraints, dependencies and risks. A requirement assumption is a condition or event that's assumed to be true or false, or that is supposed to happen or not, that directly influences the requirement's context. On the other hand, a requirement constraint is an imposed limitation to the requirement's context. A requirement dependency is a direct correlation between two or more requirements, where the result of one requirement influences the outcome of others. And a requirement risk is the uncertainty of a requirement. For example, consider a project to develop a shopping website. One of the business requirements is to allow customers to perform credit card payments for their purchases. This particular requirement assumption presumes that customers will both own a credit card and be willing to pay with it online. If we would limit credit card payments to U.S. customers only, we would be dealing with a requirement constraint. The requirement would have an additional assumption and at the same time a requirement dependency on another requirement — that the website must be capable of handling credit card transactions. On the other hand, one of the requirement risks would be the security of payment transactions. While this may seem like too many factors to keep track of, gathering these related elements doesn't have to be difficult. Personally, I document requirement assumptions, constraints and dependencies in a dedicated log, and include them as part of the project scope statement. I also use them while sequencing activities on the project schedule, and for assigning activities leads and lags. Concerning risks, I consider project scope and project requirements as two of the main sources for identifying risks on a project. Interestingly, another risk will be the assumptions, constraints and dependencies themselves, because they can also create a negative or positive possibility of risks. Regardless of the risk source, I recommend tracking requirements risks in the risk register and addressing them during the scope-definition stage and as part of the risk management process throughout the project. How do you manage requirements assumptions, constraints, dependencies and risks on your projects? |
5 Steps to Master Requirements Prioritization
| Requirements prioritization is a recognized project management practice. It's a decision-making process that enables project managers to focus on the deliverables that add the most value to a project's outcome. It is quite rare that projects are conducted without time, scope and budget constraints. Most projects will likely need requirements prioritization. Sometimes the prioritization process can lead to conflicts between the project beneficiaries. You might have to scope in requirements that address one person's needs, while de-scoping other requirements that address someone else's needs. This five-step approach can help a project manager master requirements prioritization without getting into conflicting situations: 1. Prioritize as a common practice Make it clear from the beginning that requirements prioritization is a common and required practice for any project that deals with constraints. Without prioritization, a constrained project could fail to reach its objectives. 2. Involve stakeholders Not everyone on the project team should be involved in prioritizing requirements, but not involving the right people in this decision-making process could lead to project conflicts or missed project objectives. The project's beneficiaries -- such as product owners, end-users or business departments -- should prioritize their own requirements. But project sponsors or organizations outside the project, such as legal departments, can be involved in your prioritization process. 3. Qualify requirements Identify and apply key qualitative dimensions that support prioritization, such as priority, severity, urgency, complexity or mandatory requirements. Then identify and apply key quantitative dimensions, such as weight or grades. Use numbers to reflect the possible grades for each qualitative dimension. For example:
Based on the qualitative and quantitative values, define a formula or matrix to apply when prioritizing requirements. For example, a requirement with high severity will get a 0.8 rating (0.8 x 1) and will be prioritized ahead of a requirement with a high urgency (0.8 x 0.7= 0.56) 5. Document the approach Document the prioritization approach in the requirements management plan as part of the project management plan. This leaves no room for interpretations, doubts or subjective biases during the prioritization process. How do you prioritize requirements on your projects? |
Guidelines to Plan and Facilitate a Brainstorming Session
| In a previous post, I referred to brainstorming as one of the most constructive and fruitful techniques to collect project requirements. Brainstorming can be similarly effective and efficient when applied to solving challenges in a project. Project managers can gather the project team together and brainstorm for creative ways to address the issues. In a brainstorming session, the project manager can take on the planner role, as well as the facilitator role. As a planner, project managers might consider the following guidelines:
|
Create a Project Plan to Reach Success
| In project management, if basic technical knowledge is lacking, or the basics are ignored or underestimated, a project's success is not guaranteed. On the contrary, mastering the project management basics is a prerequisite for project success. PMI's 2012 Pulse of the Profession revealed that organizations that use basic, standardized project management practices have a 71 percent success rate, compared to the average success rate of 64 percent. One of these basic pillar practices is taking the time to create a realistic implementation plan. But how do we build a comprehensive, yet realistic project implementation plan? Here are a few tips: 1. Start the project plan while keeping the final objective in focus. Write down and highlight why the project is being conducted and what the project objectives are. 2. Make sure that the project's requirements and overall project scope are clearly captured, along with the project deliverables and the given constraints. 3. Implement a well-defined change management process, agreed upon by all stakeholders. The Pulse report revealed that of the projects that used change management, 71 percent were successful. 4. Document the estimated project costs, the funding approach, how the actual costs will be monitored and how cost deviations will be handled. 5. Plan how project communication will be managed. Who are the project stakeholders? What are their project roles and responsibilities and how can they influence the project? 6. Do not underestimate the risks the project can encounter. The Pulse also showed that 72 percent of successful projects used risk management. Assess and document risks throughout the project and plan for mitigation and contingency approaches. What role does project management basics and the project plan play on your projects? To discuss Pulse of the Profession on Twitter, please use #pmipulse. See more on the Pulse of the Profession. |





