Managing IT Project Risks – Part 1 of 4: Project Specifications

This post was written prior to our January 2017 merger, under our previous firm name, MacPherson Leslie & Tyerman LLP.

It is well documented that information technology (IT) projects have an alarmingly high failure rate, and that failures can range from significant budget overruns to scheduling delays to complete project failure. This blog series will identify some of the key IT project risks that can impact both customers and vendors, and will offer some suggested tips and techniques for mitigating those risks. The topics that will be covered in this series are as follows:

  1. Determining Project Specifications;
  2. Protecting Your Business (Confidential Information and IP);
  3. Dealing With Scope Creep; and
  4. Contract Management.

The related blog posts on this topic will follow.

Defining the Project Specifications (or I Don’t Know, What Do You Want?)

Knowing what you want and what you are getting from the vendor – it seems like it should be simple and straightforward, but a surprising number of project failures are a direct result of overlooking this step. Specification breakdown can happen for many reasons, from the specifications not being developed correctly, to the use of too many shortcuts, to the users not understanding how their requirements are reflected in the specifications (and then adding requirements or changing specifications later in the project), to name just a few. The importance of allocating time and resources to the development of the project specifications cannot be overstated, and the more complicated the project, the more work that needs to be done prior to deployment.

Establishing a checklist or process for the development of the business requirements and project specifications is a simple way to mitigate the risk of specification breakdown. A sample process may include the following:

Step 1: Assessment of Business Needs

The purpose of this step is to answer the key questions of “What do we want to do?” and “Why do we want to do this?” The issues that should be considered include the following:

  • What is the business problem? How does this impact the overall business strategy?
  • What are the expected business outcomes, and what are the key indicators of success?
  • Who are the key stakeholders, and when/how will their input be provided?

Step 2: Feasibility of the Solution

The purpose of this step is to determine whether the expected business outcomes are achievable. The following matters should be considered:

  • Is the project definable and can its scope be limited?
  • Does the organization have sufficient resources (time, personnel, financial, etc.) to undertake the project?

Step 3: Business Readiness

The purpose of this step is to clarify the go-forward project approach, as well as to ensure business readiness to undertake the project. A high level business case could be generated, including details on the project goals and justification for the project investment, as well as project cost and schedule estimates. The following issues should be considered:

  • Are the business requirements fully defined? Have the users/stakeholders been involved in this process?
  • What are the project dependencies? Have the business risks been sufficiently addressed in order to proceed?
  • How much business environment and/or process redesign will be required as a result of the project? How will corresponding business change be decided upon and achieved?
  • Are the proper personnel engaged relative to the project difficulty?

Step 4: Detailed Project Plan and Project Specifications

The purpose of this step is to outline the detailed project plan and to define the project specifications. The issues to consider include:

  • What business outcomes are required for project success, and how will the outcomes be measured? Who is accountable for attaining the business outcomes?
  • What are the substantive schedule and budget estimates (including assumptions and contingencies) for the project?
  • What is in scope for the project? What is out of scope?
  • How is the solution defined? What are the high-level functional, technical and performance specifications? How do these align with user requirements?
  • What is the supporting business model and/or business change management plan?

Ideally, the decision as to whether to proceed with deployment (i.e. to carry out a procurement process or to make a major spending commitment) should take place after all of these items have been reviewed and considered.

Specifications Matter to the Vendor, Too

From a vendor’s perspective, it is also important that the project specifications be properly developed and well defined. This will help ensure that the customer’s and vendor’s expectations are aligned, and will help avoid unclear requirements which could increase the amount of time and effort involved. In particular, if the vendor is committing to a fixed price (with few assumptions or contingencies built into the price quoted) then it is in the vendor’s interest to ensure certainty of scope and specifications.

Further, in circumstances where the customer has not established clear project specifications, it often falls to the vendor to perform the analysis necessary to turn the customer’s “vision” into specifications and a project plan. As such, it will also be important for the vendor to spend sufficient time to understand the objectives, scope and deliverables of the project, and a process similar to the above could be utilized. Prior to undertaking the project, the vendor should have the customer sign off on the completed specifications and project plan in order to ensure that both parties have a clear understanding of the project and deliverables.

Conclusion: Get the Specifications Right

From both a customer and a vendor perspective, ensuring that appropriate time and resources are spent at the front end to ensure the project specifications are correctly defined is a key component in ensuring IT project success.

Read part 2 of this series – Protecting Your Business.

Note: This article is of a general nature only and is not exhaustive of all possible legal rights or remedies. In addition, laws may change over time and should be interpreted only in the context of particular circumstances such that these materials are not intended to be relied upon or taken as legal advice or opinion. Readers should consult a legal professional for specific advice in any particular situation.