Portals eNewsletters Web Seminars dataWarehouse.com DM Review Magazine
DM Review | Covering Business Intelligence, Integration & Analytics
   Covering Business Intelligence, Integration & Analytics Advanced Search
advertisement

Resource Portals
Business Intelligence
Business Performance Management
CRM
Data Integration
Data Quality
Data Warehousing Basics
EAI
EDM
EII
ETL
More Portals...

Advertisement

Information Center
DM Review Home
Web Seminars & Archives
Newsletters
Current Magazine Issue
Magazine Archives
Online Columnists
Ask the Experts
Industry News
Search DM Review

General Resources
Bookstore
Industry Events Calendar
Vendor Listings
White Paper Library
Glossary
Software Demo Lab
Monthly Product Guides
Buyer's Guide

General Resources
About Us
Press Releases
Awards
Media Kit
Reprints
Magazine Subscriptions
Editorial Calendar
Contact Us
Customer Service

Harvesting Your Own Projects

  Article published in DM Direct Newsletter
October 10, 2003 Issue
 
  By Stephen R. VanArsdale

There is an old law that trips up good intentions. It's not complicated, but I know it's easy to forget. It has to do with being prepared when there's bad news to deliver, but being better prepared when there's good news. This applies to projects.

Let's start with what we know.

  1. A project is a temporary endeavor to create a unique product or service.
  2. All organizations do projects.
  3. Most projects are planned.
  4. Most projects exceed the planned budget or schedule or both.1
  5. All projects that exceed budget or schedule or both are audited. The audit is formal or informal, regretful or serious but always too late.
  6. Good projects that don't exceed budget or schedule are not audited and shamefully waste the value that you created.

Here's an idea. Why don't we get a jump on things that are going wrong, before they do? Why not take advantage of those projects where your team did everything right and get all the credit that you so richly deserve?

You must get your projects audited. When you do, audit them yourself. The effort pays for itself.

First, let's make sure that we address a common misconception. A good audit isn't just for the boss. A good audit benefits the project team and the sponsor more than the executioner. It's true that sometimes the audit results are used to bash somebody or assign blame. But a good auditor is there to find the gold as well as the bad news. And to make both visible, such as when a project is late because the deliverables were gold-plated. All projects have problems but sometimes wiping the dirt off the bad bits of the project can bring out the silver lining as well. For example, an inexperienced team member took too long on a project but became an expert in the process. The important thing to remember is that only a poor auditor makes it a goal to punish the gallant who toiled. A good auditor relentlessly seeks out ways to help and publishes the good news and the bad on the same billboard. It's to your benefit and your team's benefit to get an audit and make certain that the auditor is helped or, at least, not hindered. The rule is: A "good" audit is not a favorable one; that's just public relations. The only good audit is one that produces news you can use.

What is "news you can use?"It's all the lessons learned and experience obtained during the project. You'll use it when you plan your next project and when you plan your next promotion. A database of this stuff is worth its weight in gold, so that's what the auditor creates. The project auditor is actually your personal historian. He is the archivist - a tireless ant - at the foundation of your growing expertise, laboriously adding bit by bit to your knowledge base of:

  • How long it takes to do specific thing,
  • How good are estimates,
  • How good are your estimates and those of others,
  • What common things happen in your organization and to whom and how,
  • What has to precede what,
  • What to do, what must be done and (eventually) what could be done.

What does it take to get a good, productive audit? Not much, so it's surprising how few times it is done. An auditor can actually spend more than 50 percent of the time and half the client's money doing stuff that could have been done beforehand to make the audit easier and more productive. A word to the wise: here's the short course in what the project auditor does, and what you'll do yourself the next time:

1. Create a Work Breakdown Structure (deliverables => activities => milestones => scheduled costs). Project standard practice includes work breakdown structures (WBS), and there's a wealth of information available on what they are. In any case, a WBS is often done after the project is underway, but it's best to make one beforehand. Everything becomes easier when everyone knows what has to be done first. More importantly, the WBS tells the auditor and anyone else who has a stake two facts. 1) exactly what is expected from the project, and 2) how it will be accomplished, how much will it cost and when will it be completed.

Here's an insight: each work breakdown structure has an optimal level of detail. The deliverables in the WBS and the levels of detail are actually constrained by something that is decided later, namely, how long it takes to deliver them. The WBS is supposed to stop at the level where the amount of work is approximately the level of control (period of follow-up). At some places this was a month and can be as much as a year, but for most projects it's about forty clock hours, or a week of work. More detail than this is usually an unnecessary burden, and less detail means that the project can be irretrievably lost by the time the project manager realizes a critical task is late. You never want to see a work breakdown structure that has elements that take an hour to complete or a month.

2. Record progress, at the same adequate but appropriate level of detail. This is the tricky part. It's much easier to do this from the very beginning of the project. The results are more revealing, and more valuable, but the real reason is that the data is more accurate. If the measurable milestones are concise and frequent enough, it's easier to know when they are done, More importantly it's easier to know when they are late. The rule of thumb is forty hours or less. Maybe this means that on a large project that the milestones become "inch-pebbles," but it certainly is easier to detect a misstep while watching one foot at a time instead of from 30,000 feet. Are you irritated about all the work involved in recording the progress of each of these tiny steps? Consider establishing weekly milestones and a weekly team status party. Or perhaps a time-recording system that gets updated every time a program or a document or a deliverable is started, when it is finished or on Friday midnight, whichever comes first.

3. Compare progress to actual, while in flight. Some people like to call these progress reviews or quality checks or status reports or phase gates. Whatever you call them, do them regularly and frequently. Whether it is formal, in front of a funding inquisition, or informally on a cafeteria napkin that gets tacked on the war room wall. Here's a good idea: since you've now broken the work down into deliverables and established short duration inch-pebbles with a known start date, end date and cost, calculate the cost variance and the schedule variance for each active task and then publish just these two simple statistics. It requires only a few minutes on the spreadsheet per week. Please remember to document and save the details on each and every completed task. It's the stuff I use to create the knowledge base during the audit and recreating it later is very time-consuming and expensive.

4. Go back and set measurable goals ... and next time do it first; it's more interesting. This step is sometimes tougher than it seems, since most projects that fail here usually started with a good plan. Make sure the goals for your project have a set of "delivery criteria." If your project has a formal set of goals, add detail to them by identifying exactly how you will show the sponsor that each specific goal is achieved. Document for yourself how you will know if it is not achieved and what will be done to correct the problem, even if the plan is to cover it up. The important thing is to have a checklist for each and every goal, including the deliverables that are necessary to fulfill the goal.

  • At 50 percent, check the goals. Using the goals' checklist (and your secret remedies list) verify the scope by determining if each goal is or will ever be achieved. Determine if the goal has been changed,or even simply "re-interpreted." For example, will all the testing of this goal or deliverable be possible or even necessary? Have features been curtailed or added? Are any additional deliverables underway or necessary? I use a numeric index to record changes in deliverables. Most important: confirm with the original sponsors and stakeholders that the preliminary results still match the original expectations and document any changes. You'll look like the hero or heroine you actually are.
  • At 75 percent, tune the project's course using Earned Value Technique and the "Sextant." This is a good time for a cool hand on the reins of the project. Intervention between 50 and 75 percent completion is rarely resented and usually most effective. This is your best shot; make it a good one. Here's a suggestion: the Project Management Institute recommends the Earned Value technique for calculating progress, and MS Project produces these numbers automatically. I put them into a projection called the Project Sextant that predicts the final outcome of each project goal or deliverable. With this kind of information you can find out what's driving the project off course and make a sincere team effort to get everybody on track.
  • At 85 percent, bayonet the wounded and clean up the mess. It's time to cull out the project deliverables that will not make it in this project. Meet with the sponsors about each deliverable or goal that is not at least five percent ahead of the project's overall percent of completion. Tell them "let's not kid each other any longer, but let's do the honorable thing." Either defer these deliverables to another project or spin off a "white space initiative" to get them done off the clock.
  • At 95 percent, plan the finish, tune the deliverables and order the band. You know what plays well in your organization. If you don't know or are new, do what I do: research a recent project that was considered a resounding success. Tailor the project results in a way that highlight the accomplishments and the heroes. Analyze the project shortcomings and turn each into a lessons-learned scenario. I've never been involved in a failed project yet that didn't have a reason, and knowing that reason usually leads to a silver lining for somebody. Harvest the silver linings and create a plan to salve the bruised feelings with some simple but sincere recognition in a public forum.
  • At 100 percent, kick the residue under the rug and bask in the glory. Don't just deliver the results like a bundle on the doorstep. Assemble the important stuff and archive the rest. Then hold the best party in best venue that you can afford.
  • At 110 percent, assess the damage (do an audit) and don't forget to reap the reward. This is the payoff. It is not uncommon to see the project manager lay down his cards, win the hand and walk away leaving the pot on the table. It is much, much harder to wrap up a good project properly than it is a bad one. Who pays an auditor to document a known success? You will, if you want on-time and on-budget projects to be the 70 percent norm in your organization instead of the 30 percent exception.2

This is where you make your presence felt. Not with an archive job or with a pedantic crossing of the Ts and dotting of the Is but with a mini-project after the real project. Here is where one converts all the boring information collected during the last 50 percent of the project into a useful, accessible audit report. I favor creating a data base, cross-referenced by text and data, date and time, deliverable and "deliverer." Other approaches include standardized forms in large binders. Whatever approach you take, the result is your knowledge base - whether you do it yourself or hire a project auditor to do it. Successful project organizations have known for decades that a project knowledge base is the very best way to plan the next project. You earned it, you should get it and you should get to keep it.

What's your next step? How are you going to cash in? Here's a final suggestion.Try out these steps right now on a project that's in progress. Quit whining about how much time it will take and just do it. In the long run, it probably will save you some time and save the organization some money. After your project is "over" (at least 95 percent), get somebody to audit your work. If you don't want to use a third party, get somebody in your organization who didn't work on the project and has no stake in the project. Give them your records, explain what went on and ask them to write an audit report. (E-mail me if you want an outline.) If the project is a success, your valor is documented. If not, you'll be the one who blew the whistle and you'll better prepared with your excuses. In any case, doing your own homework in advance pays off handsomely at the end, win or lose

References:

1. CHAOS - The Standish Group Report © The Standish Group 1995. The Standish Group, 196 Old Townhouse Road, West Yarmouth, MA 02673. 508-760-3600. Http://www.scs.carleton.ca/~beau/PM/Standish- Report.html
2. Ibid.

...............................................................................

For more information on related topics visit the following related portals...
Project Management / Development and Strategic Intelligence.

Steve VanArsdale is a certified project management professional (www.pmi.org), contract project manager, mentor and professional project auditor with more than twenty years of experience in IT. He has worked in the areas of insurance, manufacturing, retail and distribution. You can contact him at steve@vanarsdale.com.

Solutions Marketplace
Provided by IndustryBrains

SAP Safe Passage for Current Customers
If your current applications are at risk, SAP Safe Passage provides a clear roadmap for solution migration with maintenance support & integration technology. View free demos now!

Design Databases with ER/Studio ? Download Now!
ER/Studio delivers next-generation data modeling. Multiple, distinct physical models based on a single logical model give you the tools you need to manage complex database environments and critical metadata in an intuitive user interface.

Save on Business Intelligence and Data Warehousing
Leverage Open Source database software and PC-based commodity hardware for an unsurpassed price/performance value. ExtenDB transforms the economics in developing a Business Intelligence infrastructure.

OrindaBuild Java source code generator for Oracle
OrindaBuild examines your Oracle database and creates a matching Data Access Object factory class and Web Service classes for your chosen SQL statements and PL/SQL procedures. Fully functional demo version available.

Help Desk Software Co-Winners HelpSTAR and Remedy
Help Desk Technology's HelpSTAR and BMC Remedy have been declared co-winners in Windows IT Pro Readers' Choice Awards for 2004. Discover proven help desk best practices right out of the box.

Click here to advertise in this space


E-mail This Article E-Mail This Article
Printer Friendly Version Printer-Friendly Version
Related Content Related Content
Request Reprints Request Reprints
advertisement
Site Map Terms of Use Privacy Policy
SourceMedia (c) 2005 DM Review and SourceMedia, Inc. All rights reserved.
Use, duplication, or sale of this service, or data contained herein, is strictly prohibited.