Displaying topic: "Project Management"

January 11, 2012

Yes, Being Late on a Project Matters

In a previous post we asked the question “Does being late on a project matter?”. In that post we note a trend toward accepting that projects will be late as the norm. Recently we’ve run into several projects that were going to be late and the consequences were grave. Some of those consequences (aside from the obvious increse in costs we mentioned in the previous post) include:

  • You (as project manager, sponsor, project team member) lose credibility with stakeholders not just on matters of schedule but in general. Simply put people either believe you don’t know what you are doing or don’t believe you tell the truth about project issues. This effects not only the project but your career;
  • Externally imposed deadlines (for example, Federal deadlines for Health Insurance Exchanges) exist in which penalties will accrue if you are late or payments from external sources (e.g. Federal matching funds for MMIS systems) are delayed causing financial hardship; and
  • Loss of funding as projects spread across budget cycles. We’ve recently seen several cash strapped jurisdictions defund existing projects simply because they don’t have the financial resources to continue them.

So, on many projects, being late matters. It could have serious consequences. The solution to lateness is not to accept it but to:

  • Accurately estimate project schedules in the first place;
  • Keep those estimates up to date and keep stakeholders informed of any changes; and
  • Identify and develop mitigation strategies for the issues causing schedule slip.

Public Knowledge, LLC’s Predictive Management Framework® provides specific techniques, based on 25 years of hands on project management experience, to accomplish all of these. It is designed to supplement project management methodologies with some practical techniques often overlooked by those methodologies. While the techniques don’t eliminate late projects they do, if followed, provide better initial estimates of effort and duration, keep those estimates up to date, keep those interested in the project aware of schedule issues, and provide a framework for mitigating the risk of schedule slip.

January 5, 2012

Scope Creep on Systems Projects

According to research conducted by Capers Jones the average amount that a software project’s scope expands from the time when the specifications are approved to the time when the system is delivered is:

  • 10% to 15% for small systems, 
  • 30% to 35 % for large systems.

This “scope creep” or expansion of the functionality usually occurs because either:

  • The systems users are able to persuade the systems developers to add various “bells and whistles” enhancements, or
  • Parts of the specifications were vague in the first place, and full exploration of their implications causes significant additional work to be added project.

The solution to scope creep has three parts:

  • Develop sufficiently complete and detailed specifications in the first place, to remove vagueness, ambiguities and room for misinterpretation,
  • Ensure that the customers (users of the future system) participate meaningfully in development of the specifications, and fully understand them and their implications, and
  • Carefully manage the change control process.

We will discuss what constitutes “sufficiently complete” specifications, meaningful participation, and management of the change control process in future posts.

August 22, 2011

Strategies for Better Systems Procurement

We were recently brought in to help a public sector client get out of a jam with a major systems procurement effort (many millions of dollars). The problem was it was too late. The approach to procurement they had used resulted in the selection of a vendor and solution that did not best meet their needs.

They had constructed their procurement around a typical strategy: Identify the 3 or 4 categories of things that mattered to them (for example: solution provider experience and viability, solution fit with requirements, and cost), weight those things, and score the vendors on them. In this case here was the problem: in these tight economic times cost was viewed as critically important and given a high weighting. Vendor’s know this and game the system by offering a minimally acceptable technical solution and low-ball the costs. They do this fully expecting to get further revenue through the change orders they know a customer will request (because they understand their proposed solution doesn’t meet the clients real needs). In the case of our client so much of the score was based on cost that the process resulted in a clearly inferior product “winning” the procurement. So what are some strategies for avoiding having an inferior product come out on top?

  • Having well defined requirements will help. This will allow you to better compare the solutions vendors propose. It is however, difficult and time-consuming to develop a detailed set of requirements. Because you don’t typically do requirements you will probably not have the skills in-house to develop these well. A third party specializing in developing requirements can pay dividends in the end.
  • Unless you are purchasing a commodity item, like pencils, consider a “value” based procurement instead of strictly a “cost” based procurement. There are multiple ways of evaluating value, for example, score the “value” of a proposed solution by considering the cost per technical point. This will mediate “cost” based gaming of the procurement.
  • We’re not suggesting total cost doesn’t matter. In your procurement strategy leave yourself room to negotiate total cost. Pick the vendor with the highest “value” but leave yourself room to cut the total cost of the proposal by cutting scope. Have a pre-contract negotiation phase where you can negotiate scope (and therefore total price) with the vendor.
  • If your local procurement regulations prohibit pre-contract negotiation consider a best and final offer (BAFO) solution. In a BAFO, you give the vendors a chance to sharpen their pencil’s (and scope) and come back with their best offer. This doesn’t always steer procurement to best value but it can help lower total costs.
  • Lastly, test your procurement strategy. Consider all possible scenarios (e.g. A vendor has a low total cost and high technical scores), document them, and run an evaluation of the results. Are the results what you thought? Perhaps you should revise your scoring strategy.

The most import lesson here is HAVE a strategy before you release a systems procurement. If you don’t procure major systems regularly (and who procures multi-million dollar systems regularly?) get some assistance with your procurement.

July 7, 2010

Client Survival Guide: Are we doing the right things?

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.

June 2, 2010

Client Survival Guide: What’ll be different when you’re done?

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.


April 19, 2010

Where do you devote your efforts on MMIS systems?

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.


April 1, 2010

Odds are your next big project will fail or be late

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.


Read More →