In continuation of the series where I explore some specific challenges per project type, here I talk about service recipients’ projects. In this situation, your organization has signed a Statement of Work (SOW) with one or more other organizations to receive goods and services as per signed contracts. Similar to internal projects, there is usually a project manager (PM) or an executive appointed to manage the relationship with the service provider, and a formal or informal steering committee can be appointed to guide the decision-making.
Challenges experienced by service recipients may include the following:
1. Uncertainty around scope in SOW
2. Messy requirements gathering
3. Struggle to define project value
Uncertainty around scope in SOW
Often, service recipient PMs find ourselves in this situation: after signing the SOW, we like everything about it except for one point—something important for the organization’s leaders but not very valuable and potentially even costly. We had to leave it there to get the project going, but now, we really do not know how it will be accomplished. After being pressured to facilitate the signing of the SOW, we might have overlooked or consciously left that dubious point in the hopes of resolving it later.
We might be able to get away without resolving this right away and even receive additional value later, if the Service Provider PM is not meticulous or if there are significant contingencies planned on this project that would allow them to eat the cost of those expected and low value changes. Either way, we recognize that this uncertainty is a potential exposure to budget overruns and will remain a stressor for us. While best practices dictate that we should not leave any ambiguity in project definition documents, such as the SOW, in reality this is difficult, if not impossible.
Messy requirements gathering
If our organization does not delegate authority for project requirements to one person as the Product Owner, and if decision by committee is being practiced, agreement on critical project requirements might prove very difficult to achieve. This is especially true if our organization lacks a process for writing an internal Project Charter prior to signing the legally binding SOW.
In most projects, especially in software product development and system implementation, it is practically impossible to collect all the specific system requirements upfront. Each consequent requirements gathering session can be a source of potential new requirements and formal Change Orders. If your team members are not on the same page about some critical expectations, this disagreement will be leveraged by the Service Provider, and, unfortunately, the Service Recipient PM might likely be blamed for any resulting cost overruns.
Struggle to define project value
Maintaining the focus of the project delivery effort on what is truly important and valuable can be tricky. As PMs, we often are not part of functional teams, since usually we support projects without any formal authority. The notion that business units have to define the project value is deeply engrained into our minds, to the extent that we may silently accept whatever direction business units are planning to go in. While value definition processes for an organization might take many different shapes and forms, the power struggle can reduce an (ideally) complex and collaborative process into merely stating and accepting subjective opinions of executive leadership.
Very often, it is left up to the PM to reconcile any differences or changes in opinion. Since each global change has the potential to impact the budget and cost, if the PM does not keep good shared records of the decision-making process, any cost overruns might be attributed to their negligence and lack of control over the process and project.
Comentarios