PM-Foundations – Creating an Effective Statement of Work (SOW)

Having spent many years on both sides of the table (client and consultant), I have a pretty balanced perspective of what makes partnerships work well. Most importantly I have seen my share of success and challenges as a result of bad client – vendor relationships. These bad relationships are often the source of less optimal project outcomes, or at a minimum the reason the team had to “win ugly”.

I have a firm belief that the quality of the partnership, and the resulting project outcomes, start right up-front when the agreement between the client and vendor is created. The goal of this agreement is to define the products / services the vendor will provide that will satisfy the client’s needs, and how the vendor will be fairly compensated for the products / services delivered. Problems with the agreement can result in a client not getting what they need, or a vendor not getting fairly compensated for what they delivered. Here are a couple scenarios that help illustrate this point:

Scenario 1: The Unhappy Client

The client sends out a Request for Proposal (RFP) to create a new web site. The client has definite ideas in mind in terms of what the new web site needs to look like and do to drive the desired benefits to the organization. The vendor expresses that this project should be pretty straightforward and they provide the lowest time and cost estimates. They are awarded the engagement largely based upon these estimates. As the project progresses, the vendor expresses that there are more requirements / complexities associated with the solution than originally defined in the SOW. Many change orders ensue and the project slips. Finally, the project is completed, but the client had to forgo certain desired features, paid more than planned, and went “live” with the solution much after the original management commitments. This is not a happy client.

Scenario 2: The Damaged Vendor

The vendor provides a proposal to develop a collaboration portal for their client. The client says that they really want to do business with the vendor, but they do not have funding for the amount proposed. The client convinces the vendor that they can “cut some corners” in a couple areas to meet the desired cost of the engagement. As work progresses, client stakeholders keep pushing for doing things “the right way”, and in the spirit of maintaining a positive relationship the vendor performs much of the work originally proposed. The project is delivered successfully, but not without much pain and additional effort on the part of the vendor.

The processes utilized to create and approve the Statement of Work (SOW) can help both parties establish a strong partnership and achieve positive project outcomes. My insights on this topic are not all about introducing overhead and bureaucracy to crank out an “iron clad” contract, but rather how the client and vendor can work collaboratively to create an agreement that sets up both parties for success (the overused term for this is creating “win-win” situation).

6 Tips on Creating an Effective SOW

1. Understanding of the Problem – In my opinion the most important element of creating a strong agreement is ensuring that the problem to be solved is well understood by all parties involved. Adequate effort must be invested in the client describing the problem, the vendor performing discovery to understand the problem and associated requirements, and the vendor describing their approach to solve the problem. Many of my experiences with bad client – vendor relationships can be traced back to when this process was not completed well. I believe that vendors can consistently separate themselves from the competition by taking the extra steps required to understand the client problem, and effectively articulate their proposed approach to solve the problem.

2. Creating an Acceptable Delivery Approach – The processes and tools the vendor will use to deliver the solution must be compatible with client processes and tools (e.g. SDLC, project management tool). In addition, the approach must be one that the vendor is comfortable using to successfully deliver the solution. If there are specific processes or tools that are critical to compliance with client methodologies, they should be understood and specified in the SOW.

3. Establishing Realistic Estimates & Targets – Both parties must be comfortable with the effort and timelines defined in the SOW. Agreeing to estimates or dates that are not reasonable or achievable will lead to problems in the project delivery process. One of my favorite statements is “the work is what it is, and just saying it will be so does not make it so”. If there are specific concerns about the estimates or timelines, it is much easier to discuss and resolve the issues before the work has started, rather than after a significant problem is encountered during the project delivery process.

4. Defining Roles & Responsibilities – Many agreements fall short in the area of defining roles and responsibilities. Vendors do a decent job of describing the resources that they will require to deliver the solution, but they do not spend as much energy on describing client resource requirements. I think it is most effective to describe the client roles and responsibilities in the context of a RACI Chart, and highlight deliverables that the client is responsible for or is making significant contributions to. In addition, it is important to highlight specific resources or skill sets that will be required to complete key deliverables.

5. Minimizing Assumptions – Assumptions are often overused in an agreement to try to protect a party against negative situations. My experience is that these assumptions are forgotten the moment the SOW is signed, and they can become a source of contention during the project delivery process. The classic “CYA” assumption found in many SOWs is “the vendor will have timely access to client resources to define requirements and approve deliverables.” First of all this statement is not actionable, and secondly it is not helpful to successful project delivery. If there are areas of concern, work together to address the issues in an actionable manner either within the definition scope of the engagement or the project delivery approach.

6. Accounting for Progressive Elaboration – Almost all agreements involve “unknowns”. The SOW must accommodate how the unknown will be turned into a known, as well as how project plans will be adjusted throughout the project delivery process. The most common way (but not necessarily the best way) that agreements account for unknowns is through the description of the change order process. A change order process is required when an unknown is not described in the SOW, and requires additional work when it is discovered in the project delivery process. However, many unknowns are associated with clarifications required (vs. change) during the project delivery process and these situations are best accommodated by reflecting iterations in the delivery approach to confirm and adjust plans accordingly.

Advertisements

PM-Foundations – Why Manage a Project?

The other day I was at a client participating in a discussion on strengthening the portfolio management processes, when someone asked the question, “Do we understand what a project is?” This question made me smile. After all of this discussion, we don’t know what a project is, really? From my perspective it is best to keep the definition of a project very straightforward. A project is an effort to achieve a specific goal that has a definitive beginning and end.

 

When you break down this statement, the following are the important elements:

  • Effort – Projects require resources to complete. These resources generally include money and people. Therefore events that “just happen” are not considered projects (many refer to these as Acts of God).
  • Goal – The goal represents the desired outcome that the project is attempting to achieve. The goal is what defines the end of the project.
  • Beginning and End – The most important element of the definition of a project is that it is a temporary endeavor. Projects always have a beginning and an end (even if the end does not represent a successful outcome). The fact that a project is a temporary endeavor is what differentiates it from an operational process. Operational processes are repeated on a day to day basis to perform on-going business functions.

While most people can quickly agree upon the definition of a project, I think the more important question in the context of portfolio management is, “Which efforts should be purposefully and formally managed as projects?” Many project management enthusiasts would respond to this question with a passionate, “Everything, of course!” I would counter that projects can be managed as actions planned and executed within the context of operational processes. For example, I have seen many continuous improvement type initiatives successfully run “in-line” with the completion of operational work. From my perspective, the organization needs to define the efforts that should be separated from operational work, and managed as part of the project portfolio. This approach allows organizations to focus on achieving successful outcomes on the efforts that directly align with business strategies / priorities. Projects that do not fit in the project portfolio are either thrown out, or completed as part of performing normal business operations.

5 Guidelines for When to Manage an Effort as a Project

Below are my top 5 reasons to formalize an effort as a project, and manage it within the project portfolio.

1. Strategic Initiative – If an effort is tied directly to one of the organization’s key strategies or top priorities, it must be formalized as a project. These efforts need the visibility and rigor that a project provides to ensure the organization is demonstrating and communicating progress on its key strategies.

2. Requires Funding – Efforts that require additional funding / resources are difficult to run “under the radar”. The project initiation process facilitates the justification and approval of funds for these efforts. This process ensures that the organization is investing in the “right” initiatives.

3. Involves Opportunity Cost – An initiative may not require incremental funds, but involves a decision to reassign resources from another effort to initiate this effort. There is an opportunity cost related to stopping or slowing the other effort. Again, the project initiation process facilitates making decisions of this nature, and ensures that resources are working on the “right” initiatives.

4. Cross-Functional – Many efforts require facilitation of decisions and coordination of resources across different areas within the organization. Formalizing the effort as a project enables the level of coordination required to ensure its success.

5. Something New – When an effort is introducing something new to the organization (e.g., process, product, or technology) the effort needs a higher level of visibility to ensure the organization is prepared to accept and effectively leverage the new capability. Formalizing the effort as a project provides this increased level of visibility.

When do you need a project manager?

I feel obligated to discuss a related and somewhat controversial question within the project management community. When should a project manager be assigned to manage a project? From my perspective, all projects must have someone who performs the role of the project manager. I do not believe that projects will be consistently successful without someone that is formally responsible and accountable for what is delivered, when, and how much it costs. The question then becomes, when should the project manager assigned be a dedicated and fully qualified project manager, rather than a person that is performing the role as part of another role on the team (e.g., team lead)? Although I am of the belief that projects are generally more successful with a dedicated and fully qualified project manager performing the role, I do think there are projects and situations that can be successful without one. It is important to understand the project and situation when making the determination of who will perform the project manager role on the team. Here are some things to consider when selecting the project manager for your project.

  • Strategic – Is a key priority or strategy of the organization tied to the success of the project? If the answer to this question is “yes”, you should have a “real” project manager assigned to manage the project. It is common sense that a competent project manager will significantly reduce the risk of a challenged or failed project. Why put a key company priority at risk by cutting a corner on the project manager role?
  • Size & Complexity – As the number of deliverables and activities grows on an effort, so does the need for a qualified project manager on the project. The best indicator of complexity is the number and type of dependencies (both internal to the project, as well as dependencies on external activities or projects). An experienced project manager is going to do a much better job managing a large and complex project schedule, than someone who is performing the function as part of another role. In addition, an experienced project manager will more effectively manage the increased level of change that comes with larger and more complex projects.
  • Resources – Is the core team and stakeholder community cross-functional? Diversity on project teams helps drive better project outcomes, but also introduces challenges in terms of leading and controlling the project. An experienced project manager will more effectively establish and manage expectations on the cross functional core team and within the overall stakeholder community.
  • Cost – Is the cost of the project material to the organization (based upon impact on the investment portfolio or operating results)? Effectively managing a project budget is one of the most common areas that trips up an inexperienced project manager. Experienced project managers understand how to prepare a budget, forecast variances, and as required, implement corrective actions.