The Project Management Institute (PMI) defines project scope as “The work that needs to be done to deliver a product, service or result with specified features and functions.” One of your jobs as a buyer of consulting services is to make sure your consultant stays within scope. That is, they are doing the work they need to do to give you what you require and no less or more.
Why no less? This one is kind of obvious. If your consultant is doing less than you need you won’t get what you require. Consultants will do this consciously if they are behind schedule and/or over budget. We see it when we are providing QA for large system projects. For example, the development vendor is behind schedule/over budget and they try and convince the client that they don’t need as much system testing or that the bugs can be fixed after the system is implemented.
Why no more? There are really a few reasons here. First if your consultant is being paid by the hour – it’s costing you money! The more subtle but important reason is even if your consultant is on a fixed price contract doing more costs time. Your projects won’t finish on time. Allowing your consultant to do more may also distract them from doing their best on more critical tasks.
How do you make sure your consultants are within scope? Here are a few simple suggestions that will go a long way to making sure what you need is delivered on time and within budget:
- First every project no matter how small should have a work plan. This can be something as simple as a to-do list or as complex as a full blown task plan identifying task, task dependencies, timing, work effort, staff assignments etc. Don’t worry the technicalities; your consultant should make their task plan available to you.
- You should review the plan before work begins and clearly understand how each to-do or task contributes to the end product you need or want. If there are tasks that don’t appear to contribute ask your consultant why they are in there. If something appears missing ask why it’s not there. Remember every work step should contribute to the end result you hired the consultant to produce. Be persistent until you get an answer you can understand.
- You should review the progress against plan on a regular basis with your consultant. Regular status meetings are a good place for this. Get them to tell you what they’ve done from the plan. Be careful they’re not doing work that isn’t listed on the plan. If they do things not on the plan ask them “why?” If they are skipping tasks on the plan ask them “why?” There may be very legitimate reasons. Perhaps they forgot something that should be in the plan (have them add it to the plan) or there are things in the plan that really don’t need to be done (have them explain why and then remove it from the plan). If there is work you think should be on the plan but isn’t raise the issue with your consultant.
- Last, as your project closes an easy way to verify your consultant has done what they promised is to review the plan to verify that each task is complete. This doesn’t guarantee what they did meets your needs – just that they did what they said they’d do.
Shouldn’t managing the work plan be the consultant’s responsibility? Absolutely. We’re not suggesting you manage your consultants plan – what we are saying is you need to continually verify the work being performed will get you what you need. Believe it or not consultants don’t always think about whether the work they are doing is leading to the result you want. Many consultants get bogged down in the day-to-day work and loose sight of the big picture.
It is prudent for you as the buyer of consulting services to verify the project scope will lead to the result you want.
This is part of a series of articles designed to help clients and their consultants have more effective and efficient engagements.
Yogi Berra said “If you don’t know where you are going, you will wind up somewhere else.” This certainly applies to consulting engagements. If you don’t begin with a picture of where you want to end up you won’t get what you want (or need).
At the start of every engagement you need to develop a clear set of expectations describing what you think will be different when your consultant is finished. An expectation can be something as simple as you’ll no longer have to deal with a specific personnel issue or something complex like you’ll have a fully functioning Medicaid system. You’ll likely have more than one expectation.
How do you go about figuring out what your expectations are? Use your imagination and pretend it’s 6 months after the consultants have completed their work. Everything is, of course, perfect from your perspective. Now ask yourself “What’s different now than when we started? What changed?”. Write down your answers. These are your initial expectations.
You need to share these expectations with the consultant at the start of the project (note: good consultant’s won’t wait for you to share it – they’ll try and drag your expectations out of you the first time you meet).
Does this mean the consultant will meet all your expectations? Of course not. When you present your expectations good consultants will inject their experience and knowledge into the conversation (that’s the reason you hired them right?). You’ll jointly develop a set of mutual expectations for your project. This is a good thing – it gets both you and the consultant bought into a common set of outcomes for the project. The jointly developed set of expectations should be written down used to regularly assess project progress and ultimately the success of the project.
Projects without a set of shared expectations wander ending up “somewhere else”. The question for you is “do you and your consultant know what will be different when the engagement is done?” If not perhaps it’s time to develop some mutual expectations.
This is part of a series of articles designed to help clients and their consultants have more effective and efficient engagements.
Medicaid Management Information Systems (MMIS) are some of (if not the) largest and most complex systems states have to deal with. We’ve been around long enough to know they need to be replaced every 10 to 15 years and are costly to develop. What most states don’t know is when developing systems of this size the bulk of the work goes into removing defects, problems that keep the system from functioning as it should. The graph below is based on information from Capers Jones (from his book “Applied Software Measurement”) for MMIS sized systems.
The graph shows most of the effort in large system development goes into removing defects. Defects can occur in the feasibility, requirements, analysis, design, and coding phases of a project. The sooner a defect is detected in the development life cycle the less expensive it is to correct. So, defects detected in requirements are relatively inexpensive to correct whereas a defect in code is significantly more expensive to correct. Once a system is in operation defects are very expensive to correct. Think about it: not only do you have to fix the code but potentially you fix documentation, retrain users, etc.
So this all begs the question – where do you put your effort and resources during the development of a large system like an MMIS? Focus on quality early (rather than waiting for the testing phase of a project) saves money. A modest investment in quality assurance or independent validation and verification up front results in real dollar savings down the road.
Large public sector projects are almost always late, we’ve already asked if this matters, today we’re going to show you just how many big projects fail or are late. We ran across some interesting data from Capers Jones (from “Estimating Software Costs” – 1998) that we turned into this graph:
The graph points out some interesting things:
- 72% of large projects (MMIS and TANF systems fall into this category) are late or fail (about half FAIL)
- Only 28% of these systems are delivered on time
- Virtually none are delivered ahead of schedule
Based on these statistics there is a high probability that your next project will at least be late. In the coming weeks we’ll analyze some of the reasons why.
Roles and Responsibilities of a Steering Committee
If you read part 1 of this series you realize a steering committee really does have a legitimate purpose (if you didn’t read it stop now and go read it). So the purpose is really important but what are you actually supposed to do as a steering committee? A Steering Committee typically performs the following roles and fulfills these responsibilities:
- Develops an operating charter formalizing these roles and responsibilities
- Develop and maintains a set of project “Vision and Goals”.
- Manages scope. The steering committee is directly responsible for determining what features, end products, or scope the project will include. The project manager is responsible for informing the steering committee what the requested scope will cost and how long it will take to deliver and then managing project resources to deliver that scope within time and budget constraints.
- Manages costs. Again the steering committee is directly responsible for reviewing and approving all costs associated with the project. The project manager is responsible for providing accurate cost information to the steering committee.
- Arranges funding. The steering committee is directly responsible for arranging secure permanent funding for the development and operation of the project.
- Manages project operational and political issues and risks. The steering committee is responsible for managing and resolving major politics and operational issues brought to them by the project manager.
- Champions business process improvement. During the project, invariably ways to improve portions of business are found. It is the steering committees responsibility to act to determine the feasibility of these improvements and, as justified, make them a reality.
- Coordinates with related projects and programs. Projects do not exist in a vacuum. Most will touch many other projects or programs in ways that may or may not be envisioned at the outset. The steering committee is responsible for coordinating with these efforts.
- Develops policy. The steering committee reviews and officially creates all policy related to the project. Typically, a sub-committee at the request of the steering committee does policy research.
- Obtains support/agreement from stakeholders. The steering committee is responsible for obtaining the support and cooperation of all stakeholders by both formal (e.g. intergovernmental agreement) and informal means.
- Resolves obstacles. Both the steering committee and project manager are responsible for resolving obstacles as they arise.
- Communicates to the stakeholders. The steering committee takes responsibility for communicating status and needs to all stakeholder agencies.
That’s it. We hope you found this series of value and use the tools we outlined here as a starting point for your next project.
Part 1 – Purpose of a Steering Committee
