Each year, as project managers we take courses and read articles and books on how to improve our project management skills: how to track the critical path, influence without authority, tackle bigger scope and bigger budgets, work with remote teams, flush out the ‘right’ requirements, engage the teams we’ll need for success and many other topics. Often, these are great courses and articles with great tips and advice that we use every day to deliver projects assigned to us. One area where PMs aren’t always included—or do not involve themselves in—is the project selection process, that pre-initiation stage where the project is still a concept, someone’s brainstorm or someone’s personal pet project.
Many projects come from the must-do category—legal, compliance, regulatory, contractual (this last one is a big area and for the purposes of this discussion it will be left in the must-do category). But what about the rest of the project requests that are raised? There are infrastructure projects, which some companies define as must-do based on end-of-life criteria, while other companies include them as part of a discretionary project, such as a new product or new functionality. There are software projects—new options, features, products, functionalities—that will improve market share, increase customer experience, provide more features that customers can buy, improve turnaround time for transactions, allow customers to have more self-serve options, cut headcount, improve security, etc. How does a company select which projects will go ahead given the available project hours in a year or term?
Many project managers become involved or are assigned after a project is approved and only focus on the project they’ve been handed; they do not question whether it is the ‘right’ project to be done. However, as a responsible project manager, it is your place—and your responsibility—to at least raise the question of how the project fits in with the company’s goals and strategic direction.
Projects that do not align with the company’s goals—projects done because someone has a personal interest or is focusing only on their own area/department—do not necessarily further company interests. Such projects will not get the proper management support they need to be really successful, they will have over-inflated benefits that look attractive but are not based on realistic data (without these good-looking benefits, they wouldn’t have made it past the selection stage) and they will ultimately fail even if they are successfully installed.
In order to ensure that the project actually benefits the company, PMs should get to know the company short- and long-term goals. Most of these are easily available in the company’s intranet, and some companies want to ensure employees are aware of the goals so they print posters that are posted in company hallways or lunch rooms. If they’re not easily available, ask your manager/director, or the person who assigns you your work. If they don’t know, then the project may not be aligned to the company’s goals.
Go through the goals one by one and work with the sponsor and key stakeholders to identify the ways in which the project does and does not align with each stated goal. If there are aspects that do not align to the goals, spell these out in the Charter. Taking the time to write this out in plan form may save you from issues being raised later in the project. Be as specific as possible; if the company goal is to improve the customer or client experience, state specifically how this project does or does not contribute to this goal. If the company goal is to be a luxury brand or to have a reputation for world-class service, list the ways that this project will help or hurt this perception; again, documenting the negatives as well as the positives may get the sponsor/key stakeholders to reconsider their approach before the project is too far down an odious road. Once you are sure that the project is aligned to the company’s goals, ensure that this is spelled out in the Charter and is signed off by major stakeholders.
Once the information is documented and approved, ensure that the project team understands how this project fits those goals. Use this information throughout the life of the project to help guide decisions, including change requests. It is by no means the only information to be considered, but should be included with other information to make sure that the project doesn’t sway from the intended goal.
Perhaps the company already does this before the project gets the approval to proceed. In this case, the exercise should be very simple to complete and most of the information will already be in the business case. In this situation, once the information is in the Charter, it will be signed off and you can proceed to the next phase of your project.
You may be surprised to find that in projects where this alignment is not considered up front, once you complete the exercise and document the findings, the project may stall as people discuss and possibly reconsider the decision to proceed. Do not view this as a time-waster or think that you are being a troublemaker—a boss or sponsor who interprets this as such probably has other reasons for wanting this project to proceed, reasons that will likely come to light through the exercise. Remember that your goal as a project manager is to deliver the project—not just any project, but the project that will benefit the company.
When you do the right project, there is engagement at all levels, there is support, and there is also increased attention and monitoring. There is also likely more pressure as this is a strategically important project. Welcome this attention as it will help you to deal with risks more effectively and prevent some risks from becoming issues.
A project that doesn’t align to the company’s goals will not contribute to the company direction—it is a project that will not meet expectations, that will attract only a handful of customers, that will actually pay back in multiple years rather than months, and that doesn’t get the attention of the senior management team when issues arise. It is the type of project we’ve all installed after arduous hours and many challenges that everyone forgets about as soon as the installation is over. This is not the project we enjoy installing—it’s the project we’re all glad is over. And this is not the project we should be doing.
Ultimately, the decision to proceed comes from the business and leadership team. If they accept that the project does not support or contribute to the company’s goals, then at least it is documented and approved, and can be referred to in later stages if the question “why are we doing this project” is raised. If that happens, you are prepared to hear this question and can prepare for the inevitability that the project will not get the attention to help it proceed smoothly.
Don’t forget to leave your comments below.
Effie Sismanis is a Project Management consultant working in Toronto, Canada. Effie has spent the last 17 years delivering IT projects for the Financial Services & Telecom industries in Canada and internationally. PMP-certified since 2004, Effie started out working in a call center, and appreciates that business knowledge is a key to delivering successful projects.