Within IT, the vast majority of activities outside the boundaries of operations and help desk are projects, i.e., \n\none-time efforts pulling together a team, with a clear goal, budget and time line, and a final handoff, which leads to \n\ndisbanding the team. And, as established in the previous two parts of this three-part series, most projects are out of \n\ncontrol.\n MORE ON SOA\n \n Three Keys to Getting Your Projects Under Control, Part 1\n \n Three Keys to Getting Your Projects Under Control, Part 2\n \n Three Keys to Getting Your Projects Under Control, Part 3\n \n ABC: An Introduction to IT Project Management\n Some facts about out-of-control projects are well-documented. According to the Defense Acquisition University:\n\nOnce a project is 10 percent complete, the overrun at completion will not be less than the current overrun. \nOnce a project is 20 percent complete, the cost performance index does not vary from its current value by more \n\nthan 10 percent.\nThe further the cost schedule index is from 1.0, the less likely project recovery becomes.\nBut how does management get projects under control? Two decades of successful project \n\nmanagement in IT, capital construction, engineering and aerospace have revealed three keys to getting projects under \n\ncontrol: plug leaks, have an idea and go granular. In the first article we explored the first key to getting projects under control, \n\n"Plug Leaks," which means to clearly define and enforce the acceptable range of diversion. In the second article we \n\nexamined the second key to getting your projects under control: "Have an Idea." To "have an idea" management and team \n\nmembers must be able to specifically answer the following four questions: Where are you going? How are you going to \n\nget there? What will it cost? What is the payoff? In this third and last article in the series we will look at the third key to getting your projects under control: "Go Granular." Go GranularGranularization\u2014not a word, but certainly a vital concept\u2014is the third key to getting your projects \n\nunder control. A basic dictum is that you have to track at one level of detail deeper than you ever have to report. In \n\nother words, to summarize and report at the task level a manager must track at the subtask level, and so on, down to \n\nactivity and subactivity levels. Here are two suggestions to help along the way: Eliminate level-loading looseness and \n\ncontrol communication at the granular level. All too often, the responsible person assumes and reports a level-loaded scenario for each major activity, leading \n\nto looseness in tracking. For example, a team plans to deliver a function within a 10-week period. At the end of week \n\none, the team reports 10 percent of the planned hours burned and of course, 10 percent completion. And so on, yielding \n\na false sense of security to management and digging a dangerous pit just over the horizon. Fear is often the driver of level-loading looseness. It is primarily the fear of reporting a slip to someone who \n\ndoes not realize that, in reality, projects do slip. A good project plan makes allowance for the inevitable slips. \n\nThe other major driver for level-loading looseness is that no one really knows all that has to be done at the early \n\nstages of a project, a task or an activity. According to the Project Management Institute (PMI), as a project unfolds, \n\nthere will be an increasing understanding of what is necessary and how to do it. It would be wise to apply that insight all the way down to the granular level. Recognize that individuals and teams \n\ncannot know everything sitting in an ivory tower as they plan, no matter at what level they operate. As time goes on, \n\nthey discover in ever-greater detail exactly what needs to be done. That is granular progressive elaboration. This has \n\nthree additional benefits. First, any deviation from the detailed plan will show up quickly. Performance lags will quickly highlight \n\nthemselves, eliminating the traditional "10 percent burned\/10 percent complete" report. Second, the project will stay on track as the initial, broader requirements are refined and the project follows an \n\never more specific map. If and when it becomes apparent that the original scope (at whatever level) was inadequate, \n\nthe groundwork will be in place to handle the deviation through the appropriate change management process. Third, the process will quickly identify any turn or change in direction that is not a progressive elaboration of \n\nthe original intent or scope, i.e., no more scope creep. It is critical to have a communication plan that assigns names and contact information to every element at the \n\nlowest granular level. Additionally, it is important to add two categories to the traditional RACI chart (see below): backup and support. BRASCI ("RACI" Charts +2)\n\nBackup: person who backs up the responsible person\nResponsible: person doing the work\nAccountable: person who gets the credit for making it happen or whose "head will roll" if the \n\nwork does not get done\nSupport: department, person(s) or organization(s) whose services are essential to success\nConsult: person(s) who must approve a decision before it is made or an action before it is \n\ntaken\nInform: person(s) who must be informed that a decision has been made or an action has been \n\ntaken\n\n\n\n\nEach person needs to have a backup person who receives a minimum of a 15-minute overview at the end of each week. \n\nDuring those 15 minutes, the responsible person briefs his backup on progress, status, significant documents, \n\npasswords, access, and so on. As a result, there is never a significant knowledge gap in the project. There is always \n\nsomeone else to turn to for specific information. The communication plan also needs to identify every support person or organization that is necessary for successful \n\ncompletion. For example, when an organization plans to install a new application, besides the usual test and QA \n\nactivities, it may require a new server, an upgrade on the operating system, increased power supply, coordination with \n\nthe load-balance system, security authentication, etc. Identifying those people and organizations early in the project \n\nwill eliminate many of the late-in-the-project panic meetings with the attendant overtime, heartburn and slips. Now the rub: Understanding where the keys are won't unlock the door. When you take the steps necessary to ensure \n\nthat leaks are plugged, and ensure that everyone has the same idea, and ensure that activities are tracked at the \n\ngranular level, you will get your projects under control. John Troyer has more than 20 years of successful experience \n\nleading teams as a project, program, implementation, deployment and department manager in a wide variety of \n\ndisciplines and environments, including DoD, aerospace engineering, IT, capital construction, finance, procurement and \n\ncost reduction.