For a college football game, the stakeholders include upwards of 100 players, a dozen coaches, trainers, medical personnel, front-office staff, fans (both in person and around the world), media, the opposing team’s personnel, the referees, and many more. In fact, all the other teams in the league and their fans are also stakeholders in each football game, because, even if only in a small, indirect way, all these people are affected by the events and outcome of the game. Stakeholder is an intentionally vague term because, in project management, considering all possible ways your project impacts others and others impact your project can be critical to your project’s success.
The reality is that many of these football stakeholders have no measurable impact on any one game, football team, or coach. The same may be true for your project. During the initiation phase, identify and document, in a stakeholder register, everyone involved in some way in the activities or outcome of your project (see Chapter 4 for much more on stakeholders, including how to prepare a stakeholder register).
Then, ask those stakeholders who else they believe should be involved or might be impacted by your project and add them to your register. Depending on the size and scope of your project, you may want to continue identifying stakeholders. There is no correct number of stakeholders; no rule of thumb or best practice to say how many stakeholders you must identify before moving onto the next task. Use your discretion and compile the list that feels right for your project.
If your stakeholder list consists of you, your project team, and perhaps your client’s day-to-day key point of contact, either your list of stakeholders is incomplete or your project may not be worth pursuing! After all, why pursue a project whose outcome doesn’t really affect anyone, when you have other, more impactful ways to spend your time?
The stakeholder project management principle is all about engagement. The more you can proactively engage your stakeholders, early on and all throughout your project, the more likely you are to achieve its intended outcomes. Stakeholder engagement helps to ensure that you and your project team have the latest and most accurate information, business requirements, and expectations and, similarly, that your stakeholders are never out of the loop, particularly as it pertains to major decisions, milestones, risks, issues, and so on.
Delivering value and quality
Your project’s success is ultimately measured, quantitatively or qualitatively, by your stakeholders’ perceived value — worth, importance, or utility — of the outcome they receive, during or after the project. If you’re fortunate enough to manage a project driven by a business case (many are, but not all) that lays out the business need, project justification, and strategy to realize the benefits of the intended outcomes, you have the baseline you need to inform your project decisions and against which you’ll assess your project’s value. Value is a subjective term, so the more assured you are of your baseline, the more confident you’ll be in your assertion of the value provided by your project. If you are managing a project without a clearly defined business case, then work with your relevant stakeholders to document the business need, project justification, and business strategy. Use those learnings to inform your project decisions and guide your team.
Like value, quality may initially seem like a subjective term. It does not need to be. With clearly defined objectives and intended outcomes, well-thought-out test cases and test scripts (or whatever instrument is most fitting to evaluate your project’s quality), quality can be objectively assessed by how many scripts passed or failed during testing. This methodology is well-suited for software development projects, for example; however, not all projects can be evaluated in such an objective manner. If this is true for your project, devote time early on with your stakeholders to devise a mechanism for evaluating project success in a quantifiable and measurable way. This upfront effort will pay dividends when you consider what worked well and what could be improved the next time you undertake a similar project.
Once your project’s requirements are well-defined and finalized, consider developing a traceability matrix (also called a requirements traceability matrix) to associate every individual test script to a test case and ultimately to a project requirement. Test scripts and test cases are commonly used in software development projects, but they may not be applicable to your project. That’s no problem! Substitute the artifacts and tools that are most relevant to your project type and you’ll be good to go. The purpose of the traceability matrix is two-fold: first, it helps to ensure that every requirement is addressed by your product and that every requirement is sufficiently tested; and second, it forces you to justify each test script to ensure your team’s effort is relevant and helps to achieve an intended outcome.
Handling complexity, opportunities, and threats
If managing a project were simple, everyone would do it, right? Most projects have some degree of complexity resulting from uncertainty and ambiguity (Chapter 5 has more on defining requirements and project scope), interpersonal conflicts, or the interactions between activities and resources. Document any potential sources of complexity in your project as early as possible so you and your project team can develop a plan to prevent complexities from becoming full-fledged issues. Complexity can sneak up on you during any project phase, triggered by some change in scope, requirements, stakeholders, value, technology, or risk.
A risk is a potential event, which may or may not come to fruition, that would impact your project if it did materialize (see Chapter 10 for more on identifying and managing risk). Notice that we didn’t say the impact to your project would be negative. Many people are risk-averse because they assume all risks are negative; that is not the case with project management. When managing your project, a positive risk (an opportunity) would lead to some benefit if it came to be. Conversely, a negative risk (a threat) would result in scope creep, schedule slippage, budget overrun, failure to deliver the intended outcome, or some combination of each.
Negative risks have the potential to derail your project and, accordingly, should receive most of your attention, but don’t assume you can just ignore the positive risks! Unrecognized or unrealized positive risks can be just as detrimental to your project as unaddressed negative risks.
Let’s assume, for this example, that Elena is about to kick off a new project to renovate the kitchen of her family’s beach house (remember, projects don’t have to be work-related to benefit from project management). Their kitchen hasn’t been updated since the house was built in 1965, although the appliances had all been updated roughly ten years ago. The cabinets, flooring, countertops, and wallpaper are all dated and need to go!
Elena contacts a family friend, Erwin, the best carpenter around, to quote the cabinetry activity. Erwin provides an estimate of $20,000 for his time and the materials and two weeks to complete the project, but he won’t be able to begin the work for at least nine months with his current workload. Elena and her family want to complete the entire project in three months, so she contacts a couple of other carpenters to compare multiple quotes. The first two quotes are out of Elena’s budget, so she tentatively accepts the third