Ensuring Project Success: Best practices in Project Delivery

Project delivery is one of the critical services that IT provides. Unfortunately, in the industry, the track record of project delivery for IT is at best a mixed bag. A number of different studies over the past five years put the industry success rate below 50%. A good reference in fact is the Dr. Dobbs site where a 2010 survey found project success rates to be:

  • Ad-hoc projects: 49% are successful, 37% are challenged, and 14% are failures.
  • Iterative projects: 61% are successful, 28% are challenged, and 11% are failures.
  • Agile projects: 60% are successful, 28% are challenged, and 12% are failures.
  • Traditional projects: 47% are successful, 36% are challenged, and 17% are failures.

So, obviously not a stellar track record in the industry. And while you may feel that you a doing a good job of project delivery, typically this means the most visible projects are doing okay or even good, but there are issues elsewhere. In this post and in the next few I will provide a quick primer to check and ensure you are leveraging the key project delivery best practices that enable more successful track record.

Key project delivery practice areas: These areas are project initiation, project communications and reporting, project management, release management, and program management. There are also a few critical techniques to overcome obstacles including how to get the right resource mix, doing the tough stuff first, and when to use a waterfall approach versus incremental or agile. I will cover the first two areas today and the rest over the few weeks.

Project Initiation – I have rarely, and I suspect similarly for you, been part of an organization where the demand for IT to deliver projects is less than the supply of IT resources to execute those projects. In fact, this over-demand is often chronic and our IT response sometimes exacerbates the situation. Because of our desire to meet the business’s wishes, and to show progress, we make the mistake of initiating projects before they or our teams are ready to start. It is critical to ensure that you have effective sponsorship, a good bead on requirements and adequate resources before you initiate the project. There is no issue with doing concept or project exploration, initial requirements and designs, high level planning or estimation, but these must all be divided from the formal project effort with a strong entry gate that ensures you have the sponsorship, understanding of the deliverable, and adequate resources. Most projects that fail (and remember, this is probably half of the projects you do), started to fail at the beginning. They were started without clear business ownership or decision-makers, or with a very broad or ambiguous description of delivery. or they were started when you were already over-committed, without senior business analysts or technology designers.  This is just a waste of money, resource time, and business opportunity.

Address this by setting a robust entry gate and be disciplined about when to start a project. If the business sponsors aren’t there, this is a discussion for you to have with that business leader. If the project is defined as overly broad or is ambiguous, don’t fall into that trap. Take the two or three most well-defined needs and split off or chunk the project into starting with just that piece. The rest will fall into place as the work is done and everyone understands better the situation. You and the business may decide not to progress further, If you decide to proceed then start up the next chunk as a separate project. And, as much as you want to get more done, don’t start the project before you have resources. As you operate your project ‘factory’ at extremely high utilization levels, each additional piece of work you add makes you less efficient and more costly. You must use higher priced contractors rather than internal resources. And your key experts that must do the work, now have to juggle one more thing and will be less effective. It would be far better for your 500 resource team to do say, 80 projects effectively, rather than 110 projects ineffectively. It is like a server that has not enough memory for the applications active on the system. More and more time is spent on overhead, paging things in and out rather than on real work. The end result is less work done in total even though more projects are active. This is a common trap that is overcome by knowing you effectiveness range and then simply prioritizing with the business. If something critical has come up then for it to be started you must ice and take off the table other projects. Make these choices with your business partners. If you maintain this balance, then you will get more projects done in the year — and that should be the true measure of delivery (not how man projects you started).

Project reporting and communication – Doing a project is a team effort. You have many staff with different backgrounds and skills from different organizations that must come together to deliver on a single blueprint to a common goal. With such a diverse team, effective communications are paramount. And yet, often, the only formal communications are those that a directed towards senior management. There are three primary audiences that a project manager should communicate formally: senior management, the business customer, and the project team. Further, the project manager should leverage the same detailed reporting and advanced analysis that they are doing to manage the project to quickly reformat into a digestible report for their audience.

Oftentimes, you find the project managers are burdened by multiple reporting systems where they are manually entering the same information two or three times. And then middle management for both IT and the business demand additional reports on metrics that are not useful and forms for approval that are bureaucratic and repetitive. Meanwhile, the critical data (e.g. risk items, resource utilization, critical path delays) are not reported broadly if at all. And the project manager is overwhelmed with the busy work versus the real task at hand.

So streamline the reporting process. Ensure your team a single, effective project reporting tool and invest in one if not. I recommend that all the but the smallest projects produce a weekly ‘4-Box’ report. This one pager can be used for all three primary audiences and ensures the project manager, the sponsor and the key stakeholders are paying attention to the important aspects of the project.

I will be placing a 4-Box sample on the reference page for your use later this month. But they key components are simple:

  • a landscape page with 4 quadrants, a left margin column and a header section
  • the header consists of the Project Title centered and Project Status in color boxes on the far right upper corner, and the project mission in small font (it always amazing how many people work on a project and do not know what it is intended to do — thus the mission on every communication)
  • the left margin contains the names and phone numbers of the project manager, sponsor, and all key participants and stakeholders. Thus everyone knows who to call if there is an issue or question
  • The upper left quadrant contains a brief description and the key milestones for the project with dates and a status indicator (e.g. completed, underway, etc)
  • The lower left quadrant box contains accomplishments and progress for the past week (or time period). There should be a brief description of progress and a listing of the key milestones or tasks completed.
  • The upper right quadrant is a listing of the key risks and issues the project faces. They should be catalogued and a status indicated (e.g. Mitigated, Underway, Open) with a color status as well.
  • The bottom right quadrant should provide what will will get done this next week or time period by milestone or significant task with dates and with owners.

Additional information can be used to augment the report, but they key is now you can use the same one page to communicate effectively with all your audiences. This ensures everyone is one the same page (literally) at a minimum of effort. Note also that we avoid the ‘ creative writing’ of project status reports that some many organizations waste time and use to put an optimistic spin on the project progress. Instead, just the facts.

By aligning your project process and teams to these two best practice approaches, you will find:

  • you are not starting projects before they are ready to be started
  • you will run your project factory at optimal output and effectiveness
  • you will lighten the overhead load on your project managers, so they can do more real work
  • your project teams will be on the same page (and thus more effective)
  • you and your businesses will know what is going on and can identify issues much earlier and solve them more quickly

In essence, you will deliver projects more successfully.

What are the variations on these approaches that you have used with success? What would you do differently? What other areas of project delivery are problematic that you have solutions for? Have a wonderful holiday and I look forward to your perspectives.

Best, Jim

 

About Jim D

Jim has worked in the IT field for over 25 years and as a senior leader for over 15 years. He has successfully turned around a number of IT shops to become high performing teams and a competitive advantage for their companies.
This entry was posted in Best Practices, Metrics and Process Improvement, Project Management and Delivery and tagged , , . Bookmark the permalink.

7 Responses to Ensuring Project Success: Best practices in Project Delivery

  1. Amit says:

    Jim,
    This is a very well written blog. Like we all know, projects don’t go out of control overnight; it happens gradually with every passing day. Senior leaders can / should contribute to improve project performance by:
    1. Asking the right questions regarding the project status even if there are no apparent issues eminent on the surface. This demonstrates and communicates to the PM that the status is being carefully reviewed by the executive
    2. Introduce some form of an early warning system focused on key elements of the project’s health to quickly assess the well being of their projects at a regular frequency.
    3. Support the Project Manager and encourage them bring forward issues / concerns / problems and understand what corrective / preventive actions are being taken to remediate them
    4. Encourage a culture of innovation and creativity as part of delivery methodology. Time and again I have seen these pay huge dividends for all stakeholders

    A good PM can ensure more consistent performance and successful outcome in managing projects and programs by focusing on:
    1. Right Strategy (Spend quality time collectively to create a well thought out strategy)
    2. Get off to a good start (Sound Project Definition, Accurate Project Estimate, Accurate Project Schedule, secure buy in from all stake holders)
    3. Control project execution (Effective and accurate project tracking, Effective scope control, Effective and quantified status reporting, Regular and frequent management oversight)
    4. Effective staffing (Right person with desired skills and attitude)
    5. Continuous improvement (push to drive efficiency)

    • Amit says:

      Jim,
      This is one of the analogies that I always show to my staff in town hall meetings. Consistent success of any program, project or initiative sits on a table with 3 legs;
      Discipline Leg 1 – Process + tools/techniques + Training.
      Discipline Leg 2 – People.
      Discipline Leg 3 – Enforcement.
      Assuming the outcome of the project is a bowl filled with water sitting on top of the table, unless each discipline leg is executed with equal focus, we cannot derive the true desired outcome planned. Shortage in any one leg will cause value leakage (cost, schedule, desired result etc).

      • Jim D says:

        Amit,

        I like the 3 disciplines approach and elements you have included. I think though I would adjust the 3rd discipline from ‘Enforcement’ to ‘Execution and Metrics’ or ‘Followthrough and Metrics’. In other words, you will get more out of the team if senior management, the PM, and the team meet their commitments and leverage metrics and reporting to identify where they are not, and then solve for it. I am sure you use such an approach and at times enforcement on its own can backfire. Does that sound right or would you take a different tack?

        Thanks, Jim

        • Amit D says:

          I completely agree with you – “Execution & Metrics” are extremely important element which I typically bucket under the “Enforcement” discipline leg too. Maybe, I should put “Execution & Metrics” as the third discipline leg and put enforcement under it….

          The point I making on enforcement/re-enforcement is – We can have a well thought out strategy & design; great project plan; best tools & templates; right team, however, if the rigor is not enforced (of course, managed in a well calibrated way with flexibility to adjust if the situation absolutely demands) to control project execution during the entire project lifecycle (by effective and accurate project tracking, effective scope control, effective and quantified metrics & status reporting, regular & frequent management oversight), the chances of encountering unwarranted surprises (delays, cost overruns, not generating desired outcome totally) are significantly high.

          Another element which I missed under the section “PM can ensure more consistent performance and successful outcome in managing projects” is Risks which, many a time, gets overlooked and dictates strong attention from all key stakeholders.

          Both senior leaders and the PM must identify key risks and closely monitor/control them at the overall program level and each phase level with an effective risk mitigation plan. Contingency (cost, time) must be carefully built in the project plan and allocated under multiple buckets to manage these risks.

    • Jim D says:

      Amit,

      Thanks for the positive feedback on the blog and I think your lists for senior leaders and PM are very helpful. I particularly like #4 for the senior leaders. Oftentimes, once the project is defined, all innovation and improvement stops and we just execute to spec — this is a great reminder that innovation doesn’t (and shouldn’t) stop once the high level design is done.

      Well said.

      Thanks,

      JIM

      • Amit D says:

        Yes Jim, Continuous improvement and innovation has always been dear to my heart. Introducing simple initiatives like “Idea of the Month” where I encourage and reward engineers to come up with an idea that can either improve productivity/efficiency or effectiveness or reduce project cost has always created an environment and culture which is exciting for all (including myself) and brings the best out of my team. Motivation, confidence, trust and passion run high which positively shows up in the results they collectively deliver.

Leave a Reply

Your email address will not be published. Required fields are marked *