Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
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? |
Project Adjournment for Virtual Teams
Categories:
Teams
Categories: Teams
| While project managers often talk about building a virtual team, they rarely discuss disbanding one. I recently adjourned the virtual team I'd led for the past four years. As a dispersed team, we initially experienced some issues around cultural differences. But we came together eventually and produced the expected results for the organization. When the time came to close the project and disassemble the team, a different kind of challenge arose. The first issue I encountered was that some team members didn't want to leave the team. Over the life span of the project, we'd built a strong bond. And there was another layer of complexity as team members' cultural traditions and values informed how they expressed their disappointment. As I helped the team to reach closure, I discovered the more "face-to-face" time, the better. I tried to reduce the distance that separated us with video conferences. During these meetings, I would explain that team adjournment wasn't a loss, but rather an opportunity to meet new people and take on new tasks. With some team members, an impromptu call before the adjournment meeting worked fine. With others, I scheduled a conference before and after the meeting to ensure they would be okay. The second challenge was preparing team members for their next project assignment. During the transition process, it was important to see their reactions, so video conferences were helpful here as well. I also tried to keep the focus on how team members could leverage their experiences in our project for their next assignment. Finally, I introduced some team members to project managers in need of skilled resources. Two of my former team members joined projects this way. In the end, the team members understood that our strong bond wouldn't end just because the project did. We're always just an e-mail or a phone call away. As a virtual project manager or team member, what challenges do you face during team adjournment? |
Tailoring Communication for Top Stakeholders
| Given the amount of work involved, most of your project communication efforts should focus on the stakeholders crucial to the success of your project. And this requires answering two key questions: Who are the most important stakeholders, and why are they important? Determining who's important is usually straightforward, based on an assessment of the stakeholder's power and involvement in the project. Understanding why each "important stakeholder" is important helps you define the type of relationship you need to develop for effective communication. Enter the mutuality matrix, a useful project communications tool that starts with two dimensions:
These assumptions create four quadrants for categorizing each of the important stakeholders:
Once you understand the mutuality matrix, the way you communicate with each of the important stakeholders can be adjusted to ensure both parties achieve a satisfactory outcome. For example, the time and effort saved by minimizing communication with intractable objectors can be invested in building relationships with your key suppliers. Keep in mind that each stakeholder will also be either supportive of or opposed to the project. Important stakeholders against the project — typically competitors and objectors — usually need nothing from the project and your communication should be focused on minimizing the objections. Similarly, important stakeholders who need something from the project are usually either passive or supportive, and your communication should be focused on building robust relationships. How do you identify and communicate with important stakeholders? |
Integrating Project Communications into Lessons Learned
| Lessons learned sessions typically focus on project deliverables and budget. But I'd recommend adding project communications to the agenda of elements to review. Take a hard look at the communications plan and how well it worked. This process should include evaluating the stakeholders listed, the way the tool was manipulated throughout the project life cycle, or even the categories listed on the communications plan, such as audience, frequency and deliverables. Then discuss other communications documents — status reports, issues lists and risk registers — and how to make them more worthwhile. Consider the frequency with which these documents were published and the need to develop communications tools specific for each of your different audiences. Finally, look at your communications with team members and executives. How you communicate with team members is different from how you communicate with management, so these should be separate areas of discussion. Yet for both groups, keep in mind how time zones, language barriers, leadership style and working relationships may have affected communications. When examining your team communications, here are a few questions to ask:
When looking at your communications with management, keep in mind that this probably required less day-to-day communications than you had with the project team. Management's interest is in the big-picture, milestone items, such as presentations on status, the budget and the go-live date. When looking at your communication with executives, ask yourselves:
One last thing to keep in mind: As with any topic in a lessons learned session, be prepared to discuss unforeseen issues. Some project communications mishaps that I have heard about include not bringing in the data owner, issues reported too late or misalignment of user feedback with a requirement. How do you evaluate your project communications in lessons learned? |
A Project Management Wish List for 2013
| Another year for project managers has come and gone. And while this is the time for all the usual year-end activities (budgets, status reports, etc.), it's also a good opportunity to look toward the future. To project managers around the world, I wish you health and prosperity. I also thought I would share a few other dreams I would like to see come true in the New Year: 1. Talking project plans. From GPS systems to smartphones, just about every device offers a verbal communications mode nowadays. The same technology should be applied to project plans. They could alert you to urgent issues: "Your resources are overloaded" or "You need to add more tasks." A talking project plan could even present an entire status report without you speaking a word. Think how much fun your meetings would be when the project plan says, "Just go home because your project will never make its projected end date." 2. Project issues that solve themselves. Project managers know that early detection of project issues is the key to staying on schedule and budget. We hold resolution meetings. We collaborate with leadership to craft brilliant solutions. Yet every so often, it would be great for issues to just solve themselves. For example, say your project is over budget. Then suddenly you get an e-mail from your project sponsor that grants extra funding due to your company's outstanding performance this year. A project manager can dream, right? 3. Resources ready, willing and able to jump into the action. We spend a considerable amount of time identifying resources and negotiating for their availability on a project. And still, we see our schedules fall apart when they're pulled away by other demands. Just once I'd like to have a project where everyone is fully dedicated, with no other distractions to threaten the schedule. It would make me very happy to hear a project team member turn down a meeting with the company president to work on my project. 4. No change requests. During the early phases of a project, we work to create the most accurate set of requirements possible. We consider it all — the many functional needs and the hidden complexities. After all that work, wouldn't it be nice if everything remained precisely the same throughout the life cycle of the project? Think of the time you could save by canceling those painful weekly change-request meetings. 5. Give back all contingency funding in the project. We typically reserve contingency funding to guard against unforeseen events. Imagine the sheer joy of having no project risks that required budget or schedule relief. Just think of the satisfaction of telling your project leadership "We have no weather, people, software, hardware or network risks, so we are returning all contingency funds!" What's your project management wish for 2013? |