Section 10.3. Monitoring Project Progress
10.3. Monitoring Project ProgressThere are numerous ways you can monitor project progress. There are also some more technical methods for tracking project status. In this chapter, we'll stick to the less technical methods and if you're interested in more rigorous tracking methods, you'll find them (along with common project problems and solutions) in Chapter 11. As you monitor your project, you have to ask four essential questions:
In this section, we'll first talk about how to gather project status data. Then we'll talk about variance to the project. Finally in this section, we'll discuss the steps you can take to deal with the variance.
10.3.1. Reporting Project ProgressReporting project status is one of the processes you should have delineated back when you were defining project processes. Status can be communicated in a variety of ways. In the next section, we'll discuss exactly how to measure progress, but for now, let's focus on the methods of communicating progress. 10.3.1.1. Team MeetingsOne of the processes we discussed earlier in the book was gathering project status updates from the team. One method that most IT project managers use is the project team meeting. Team meetings not only help people stay focused on the project, they help build that sense of teamwork that can be crucial to project success. Well-run team meetings also give people the opportunity to stay up to date on the overall project progress and gather information that may be helpful in accomplishing their work. Sharing best practices or lessons learned benefits the whole team and can help others avoid similar problems. In addition, team meetings are a good place to discuss project status because changes to one task or work package can impact many other tasks down the line. Having everyone in the same room (or tied in by video or phone) to discuss status and changes can help resolve issues before they get out of hand. Team meetings are also where problems should be raised, discussed, and resolved. Having this regular forum for project work helps prevent side conversations and agreements from occurring. It's not uncommon to have one or more members of the team approached by a member of the user community to request a "small change" to the project. These are very dangerous to a project plan and should be avoided. By holding regular team meetings and encouraging team members to discuss these kinds of requests and issues, you can keep everything aboveboard, manage these requests through your standard project processes and hopefully avoid (or manage) scope creep. 10.3.1.2. Status and Progress ReportsYou may ask for status or progress reports during team meetings or you may want those sent to you via e-mail prior to the meeting. Whatever method you've developed for gathering project status and progress, make sure you use it consistently. One common occurrence is that project status reports are consistently required at the outset of the project, but as time wears on, everyone gradually gets a bit lax in their reporting and before you know it, you have no current project data. Current data is the only way you can control the progress of the project, so it's the key to project success at this point. The best way for people to report on status and progress is to record their activities in real time. Studies consistently show that the longer the interval from work to recording, the more inaccurate the recording is. Encourage team members (task owners as well as those doing task work) to record their work as they're doing it. Their data will be much more accurate and it will give you a better view into the status of the project. If people wait until the end of a work week to record details about their project work, there is a very strong likelihood that the data will be skewed one way or another. If you've ever waited a month to fill out an expense report from a trip you took, you know how difficult it can be to re-create the data. You have to go back through your e-mail, calendar and receipt files. It takes very little time to record activities in real time and it provides the most meaningful data. Encourage team members to be truthful in their reporting as well. The tendency is to minimize problems so we don't have to deal with them, but eventually the problem flares up and it's far more difficult to deal with it once it doubles or triples in size. Consistently look for bad newsthe good news will jump out at you with little effort. That doesn't mean taking a pessimistic attitude toward the project; it means that if you don't look for the bad news, you might not see it until it's too late. If you and your team have a good attitude toward bad news, you might devote a portion of your team meetings to "the bad news you'd rather not tell us" where each team member is asked to divulge something about their section of the project they might not otherwise share.
10.3.1.3. Issues LogsPart of reporting status and progress is creating and managing an issues log. There are many different approaches to issues logs, but they essentially all have the same functionto track problems that arise. Each issue should have a brief name and description, a category (the part of the project in which the problem was found), an owner (who will take action to resolve the issue), an origination date (when it's entered in the issues log), a recommendation date (the date a recommendation is due), a resolution date (the date resolution is due), and a completion or close-out date (when the issue was considered resolved). If it's helpful, you can create an issue numbering system so issues can be grouped or referred to by number since unique issue names may become cumbersome. Remember, too, that there may be some issues that require no action. These should be noted and closed as resolved with comments as to why no action was recommended or taken. While this might seem obvious, it's easy to get in the mind set that each issue requires some change. Though that's often the case, the option of doing nothing should be considered. Some issues actually do resolve themselves. Some people find it helpful to use a spreadsheet to track issues. Some companies have specific software designed for issue tracking (in software development, there are usually issues logs and bug or defect logs). Whatever system you implement, make sure it's easy for team members to add issues (if you want them updating the log) and make sure it's easy to find, sort, and analyze issues as well as to quickly and easily determine the status of issues (open, closed, pending, at risk, critical, etc.). Bugs or software defects can be considered issues, but more often they are tracked separately in a bug tracking system. An issue might be that the code specified for Part 4 doesn't interface with one of the legacy systems. A bug might be that the code written for Part 4 doesn't work as specified. Essentially, an issue in software development is typically related to functional or technical specifications whereas a bug is a problem with code written to a specification. Bugs or defects should be tracked in a similar manner as issues, but they generally go through a different resolution cycle. Bugs or defects typically are sent back through the work cycle for repair either during current work or as a separate work cycle. You can download a bug tracking template if you don't already have one. There are three common problems with issues logs worth discussing: no owners of issues, no follow up, and lengthy or repeated issues discussions. Let's look at of these problems briefly. 10.3.1.3.1. No Owners of IssuesJust as a task without an owner will not get done, an issue without an owner will not be resolved. Issues should be assigned owners so that they can be researched and resolved. As the IT project manager, you are the default owner of all tasks. It's safe to assume you don't want to do all the project work single-handedly, so check to make sure all tasks have appropriate owners. The owner should be responsible for researching the issue and making recommendations for solutions. Depending on the type of issue, the owner may recommend the solution or bring the problem to the team for discussion. Once recommendations are made, the owner (or team) should make a decision on a course of action and implement that action. 10.3.1.3.2. No Follow-UpIf no one is checking the issues log on a regular basis (that's typically the job of the IT project manager), then it's likely people will stop updating the issues log. Worse, they may stop taking action on issues and that puts your project at risk. Part of each team meeting should be a review of the open issues and updates relevant to the issues log. Don't spend a lot of time on this. A quick update should suffice such as, "Hey, Phoebe, what's the status of Issue 123? Do you think you'll have a resolution by Thursday?" Make sure you touch upon each open issue so that owners are held accountable for closing issues in a timely and reasonable manner. Otherwise, as your attention to the issues log wanes so too will theirs. 10.3.1.3.3. Lengthy or Repeated Issues DiscussionsWe all know how painfully boring it can be to sit through a lengthy discussion that does not involve us. It's why some people start ducking out of meetings or not showing up in the first place. If an issue requires lengthy discussion by the entire team, it should be on the agenda as a separate agenda item whenever possible. If an issue prompts discussion, it might be worthwhile to discuss it as a team, but if the issue does not impact a majority of the team, don't make everyone sit through an irrelevant discussion. Table it and have the interested parties discuss it outside of the regular meeting time. Going through the issues log should not be a long, arduous, and painful process, though in some companies that's exactly what it is. Make sure the issues log is used as a tool and that you use it as intended. If your issues log is long (in some large projects, the issues log can become very lengthy), you may have a separate issues log meeting. In some cases, you may break it down further and have issues log meetings for subsets of the project team to avoid discussing endless detail on a topic a majority of the team does not need to know or hear. Also, avoid rehashing the same issues over and over. Determine a course of action, request updates, and move on. If an issue keeps coming back up, it's important that you, as the IT project manager, take a look at this and figure out why you keep discussing it over and over. This problem often occurs if notes are not kept that capture the discussion and decision points. It's important that you develop a course of action and resolution for issues because rehashing those issues repeatedly is a waste of time and will de-motivate the team quickly (not to mention the risk it injects into the project). 10.3.1.3.4. Managing EscalationsSometimes problems occur in projects that require the assistance, input, or decision of someone higher in the organization. Your escalation procedures should be well established before work commences so that task owners and team members know how and when to escalate issues. Your issues log is certainly the starting place for raising, tracking, and managing issues, but sometimes these issues require additional input for resolution. Make sure the criteria and process for escalating issues is clear to all team members. On one hand, you don't want to "cry wolf" and escalate every little issue you and the team run into. On the other hand, executives hate surprises so it's important to understand how, when, and why you should escalate issues. This is one part project management, one part change management, and one part risk management. Issues that are difficult or impossible to resolve that impact the project's overall scope, critical path, or functional deliverables should certainly rank high on your list of potential escalation candidates. The criteria you and the IT project team establish should have been reviewed and cleared with the project sponsor so you know exactly which issues should be brought to a higher level in the organization. Using team meetings, status and progress reports, and issues logs, you have three fundamental tools at your disposal to know what is going on in your project. You're probably familiar with the data processing saying "Garbage in, garbage out." Your project data is only as good as the data people put into it. Current, accurate data will help you recognize problems quickly and take appropriate corrective action. You can download an issues log template from the Syngress website if you don't already have a format you prefer. 10.3.2. Risks and Contingency PlansWe'll discuss managing risks and contingency plans in more detail later in this chapter, but during the course of your project work, you should keep your risk management plan handy and make sure you're aware of your risks and trigger points. Ideally, you should have placed milestones in your project plan to remind you of potential or upcoming risks and trigger points. For example, if you know that only Joaquin can write a particular section of code, you should have a checkpoint prior to that work package to check that Joaquin is available for this task at the scheduled time. It wouldn't be helpful to find out the day before work on that task is to begin that Joaquin just took off for a month in Mali. Make sure you review your risk management plan and keep an eye on your trigger points. Build them into your schedule if you haven't already so that risks and associated triggers are kept in the forefront. Remember, too, that implementing "Plan B" is a change to your project and must be addressed through your change management procedures. During the risk management planning phase, you should have identified the major areas that might be impacted by your "Plan B," but once work commences, the picture may change. Make sure you look ahead and think about how potential contingency plans might impact the project at this point and going forward. While you won't have time (nor would it be advisable) to plan this way for every single risk, you usually get a sense for which risks are most likely to occur and which require additional thought. 10.3.3. Determining Project ProgressTo manage your project, you must know where you wanted to be (that's defined in your project plan) and where you are (current project status). The current project status is something that people sometimes think means progress against budget (if cost is the least flexible element) or progress against schedule (if time is the least flexible element). However, if you measure a project's progress against just one parameter, you have a very lopsided picture of the project. Let's look at an example. Suppose Patty was assigned a task to write a particular section of code for a new application. The schedule estimates that it's 10,000 lines of code and that it should take her fourteen work days to accomplish this. For the sake of this example, let's assume Patty makes $25/hour. At the halfway mark, on day seven, Patty has 7,000 lines of code complete. What is the status of the task and how does that impact the project? You could say that since she's seven days into the task that she must be 50% complete (schedule). However, she has 7,000 lines of code written, you could also say that she is 70% complete (lines of code or deliverable). What if we also included the fact that Patty has spent 84 hours on the task because she worked 12-hour days instead of 8-hour days (7 days x 12 hrs. = 84 hrs., 14 day x 8 hrs. = 112 hrs.)? You might say, well, she's expended 75% of the hours needed, so she must be 75% complete. You might also say that if she's 75% complete at the half way point that she must be ahead of schedule. Which, among all these statements, is actually correct? Let's look at the cost factor. The total cost of this task was estimated to be the cost of Patty's wages$25/hr x 112 hours or $2,800. Patty has completed seven days of work, but she incurred overtime on all seven days. The current tab is (($25 x 8) x 7 ) + (($37.50 x 4) x 7) or $2450. That's about 87.5% of the total budgeted cost. If she is on salary, the cost of an 8-hour day and a 12-hour day would be the same and she'd have expended 50% of the task budget (remember, we're talking about cost here, not effort). Clear as mud, isn't it? Let's recap: Patty is 50% complete, 70% complete, 75% complete or 87.5% complete, right? Patty is on time, ahead of schedule, or behind schedule. That's not very helpful, it is? What if we also said that Patty ran into a huge problem and that although 7,000 lines of code are finished, she now estimates that it will take 25,000 lines of code to complete this task? Suppose working all that overtime to get this task completed caused Patty to make several key errors in the code and the remaining work might take twice as long? Suppose Patty is a genius (which we all suspected anyway) and she actually found a better way to write the code and it's complete at 7,000 lines of code? What is the status of the task now? As you can see, there are a number of variables to consider. There are always these kinds of variables and it's impossible to know absolutely everything. Some task progress will be much more tangible and easy to assess. In other tasks, like Patty's, tracking progress can be a bit more elusive. You can see by this example that by tracking more than just one element (more than just time or just cost), you can at least get a much better idea of the actual progress. Getting Patty's perspective on her progress and remaining work can be very helpful and can be an important part of understanding progress, especially in knowledge work. 10.3.3.1. Project Progress and Knowledge WorkKnowledge work (the work done in many IT projects) is quite different from other kinds of work. In fact, work in knowledge areas (such as programming) does not progress along a linear path. Its path looks more like the trajectory shown in Figure 10.4 Thus, progress may appear to be slow or lagging in the early stages of work and the work gets completed quickly at the end. Knowledge work often follows the 80/20 rule80 % of the work is accomplished during the last 20% of the project. Stated in reverse, it typically takes 80% of the task time to accomplish the first 20% of the work. This is partially attributable to the learning curve associated with most knowledge work. Figure 10-4. Progress Curve for Knowledge-Based Tasks or Work As you can see, there can be a lot of difficulty determining project status for just this one task. The challenge, of course, is to figure out how to accurately determine the task and project status in a relatively fast and simple manner. If you don't take scope, time, cost, and quality into account, you won't have a clear picture at all, so let's look at some methods you can use to account for these different measurements. There are several methods used to track project progress that give a clearer view of things. We're going to discuss the basic ways to do so and we'll discuss some of the more advanced methods including Earned Value Analysis, Cost Performance, and Schedule Performance (among others) in Chapter 11. The methods in this chapter (Chapter 10) are suitable for many IT projects, but some projects (or some companies) require the more rigorous tracking methods discussed in the next chapter. 10.3.3.2. Percent CompletePercent complete is probably the easiest method for assessing project progress and it's one many people use. If you're going to use percent complete, you should track both percent of budget expended and percent of schedule expended. When possible, it is ideal to also track percent complete of the deliverable work itself, though this is not always feasible. If you track against both cost and time, you will instantly have a better picture of what's going on than if you just tracked cost or time. Since percent complete is often a judgment call, it's not always an accurate measure, but it's often the best (or only) measure we have. If we use our earlier example of Patty's code development task, we can say that she is 70% complete because she has 7,000 of 10,000 lines of code complete (deliverable). We can also say that she is 75% complete because she has expended 75% of the hours (effort) allotted for this task. Since she's completed 70% of the code and expended 75% of the time, we might actually conclude that she's running a bit behind because we would expect to see 75% of the work completed once 75% of the effort had been expended. Are we in trouble on this task? It's difficult to know since Patty might have figured out a way to do this task with 7,500 lines of code, she might run into a problem that causes her to be delayed in completing the final lines of code, or she might have to spend significantly more hours to complete the code (according to scope and requirements) on time. We also know that for knowledge work, it can take longer to complete the early stages of the task so Patty might make up the time on the back end and come in ahead of schedule. Again, Patty's the subject matter expert in this case, so her perspective about the task's progress should also be taken into account. In this case, effort and duration are quite relevant, so we might choose to focus on Patty's hours compared to duration. For instance, she has expended 75% of the estimated hours (effort) in 50% of the duration (schedule), so we might conclude she is ahead of schedule. If she had expended only 25% of the hours at the 50% mark in duration, we could reasonably conclude Patty was behind schedule. Remember that the original time and cost estimates were developed based on subject matter experts' opinions (possibly Patty's own estimates for this task) or on historical data. However, they were still estimates. So, the estimate of what it would take to complete the task is really an educated guess and the estimate of where the task or project is now is also a bit of an educated guess. You could spend hours and hours of time trying to nail this down more exactly, but in many cases these educated guesses are as good as it gets (well, from a cost/benefit perspective, they are as good as it gets). So, percent complete isn't perfect, but it does give you some idea of what's going on, especially if you use percent complete for schedule and budget and include percent complete of deliverables when possible.
10.3.3.3. VarianceMeasuring variance is another commonly used method to measure project (or task) progress. Variance is typically represented as a percentage over or under plan. By definition, variance is the amount a result differs from the plan or baseline expressed as a positive or negative number (or percentage). A positive variance means the actual is better than the plan; a negative variance means the actual is worse than the plan. Variance can be an extension of the percent complete method because variance can use actual numbers or percentage of completion for measurement. First, let's recap the data for this task, shown in Table 10.1.
For instance, we could say that Patty has expended 84 hours at the halfway mark, so she is 28 hours over the effort estimate, a -28 hour variance (plan minus actual or 5684). We could also use percentages and say that she has expended 75% of the hours at the 50% mark and therefore has a -25% variance (50% - 75%) on estimated hours. Without knowing how much work she's accomplished, though, her actual hours don't tell us the whole story. Some IT project managers like to manage using variance because they can focus on the things with the greatest variance. One method is to calculate variance and assign a risk category to that variance. Any task falling into a medium to high risk variance category gets extra attention. An example of this type of categorization is shown in Table 10.2. You can modify this to suit your needs, but the point is that anything with a large or significant variance from plan should be investigated immediatelythat includes things that are reported as significantly under budget or under schedule. For example, tasks that have a variance of 51% or more may require work on the task or project to halt until the problem(s) can be resolved. Anything that has a significant variance should be investigated because it can mean only one of two things: your estimate was wrong or your task/project is at serious risk. If you're have a large variance under estimates you shouldn't assume things are going extraordinarily well (though you should be open to that possibility). Rather, you should wonder if the scope or quality is being met, if someone skipped a step or forgot a key work package component, or if someone is simply fudging the numbers to make themselves look better (yes, unfortunately, that does happen). Of course, you need to also be open to the possibility that someone was innovative, creative, or flat-out brilliant and came up with a better solution that took less than half the estimated time. It can happen, but remember, things are more likely to accidentally go wrong than to accidentally go right, so keep a healthy dose of skepticism handy when reviewing variances.
Let's return to our example of Patty the code writer. Let's recap the stats on this task and look at the variance at the same time, as shown in Table 10.3. The various data described earlier is summarized in the table. By noting the scheduled or planned versus the actual and noting the variance, you get a better picture of what's actually going on in this task. As you can see, the Expected column is the calculation of where we should be at this point. Part of the task detail might be a progress checkpoint at the halfway mark, other times this data will be developed on the fly. You might choose to create these kinds of checkpoints (milestones) for all tasks on the critical path so that you can analyze these tasks more thoroughly.
You might look at this and ask why effort and deliverable are at red status when the deliverable appears to be ahead of schedule. The key is that according to the framework laid out in Table 10.2, anything that is out of variance by 26% or more should be looked into. In this case, there's a simple explanationPatty is getting ready to go on a four-week vacation to the Mediterranean and wanted to complete her task early in case there were any issues with her code. She's been working overtime (she's salaried, so there's no additional incremental cost) to complete her work early. That may be the only explanation needed. Let's look at another scenario. Suppose Patty completed those 7,000 lines of code in just four days, but she's been stuck on the 7,001th line of code for three days. She's expended 75% of the allotted time to accomplish about 70% of the work, so that would normally look like things were moving along. In truth, she's come to a dead halt. Will your variance report tell you that? Not in this case, but since you're looking into these large variances, this information should come to light. By noting the variance and investigating it, you can find out whether Patty is truly ahead of schedule or whether this variance might be an indicator that something is going wrong. Patty's input on task progress would indicate whether she is at a dead halt or whether work is progressing as expected. What about scope and quality? Are those in or out of variance? Scope and quality are both defined within the task. The total amount of work to be accomplished for Patty's task should be clearly delineated in a requirements document and again in the task detail. Although we've talked about an estimated 10,000 lines of code, the scope and quality information will define what that code should do (one could write 10,000 lines of code that do nothing or do the wrong thing). The entry/exit criteria or completion criteria should be clearly delineated, as should the quality metrics. Although it is possible that Patty's code is poor quality or does not address the scope, you have to assume that because Patty was given the task that she is capable of understanding and delivering on the requirements. As the IT project manager, you can't micromanage every project task so you have to trust others to get their work done according to specifications. That said, there should be built-in checks and balances and in an IT project, this often is accomplished using entry/exit criteria, completion criteria, quality metrics, and through testing tasks or phases. The task owner (whether that's Patty or the Director of Software Engineering who assigned Patty to the task) is responsible for performing to specifications and your job is to ensure each task is making required progress. The point is that you usually cannot clearly quantify scope or quality as easily as time or cost in terms of how much variance there may be from plan until a task is complete. For instance, if Patty's code turns out to be 9,945 lines of code but does not address one required feature, the scope has been reduced. Could you have known the scope was being reduced when the task was, say, 75% complete? Maybe, but not as easily as you could determine that the task was on schedule or on budget. The same goes for quality. There's often no reasonable way you can know if Patty's work meets or exceeds quality standards until it's tested, which is generally a separate task or phase. Thus, it will be difficult to know if there is significant variance in Patty's work in terms of scope or quality until it's completed. Most IT projects have built in ways to determine if there are variances to scope or quality once a task is complete, but generally do not try to track that during task work itself. In some cases, you may be able to track variance to scope or quality within the confines of the task. If it's possible and useful, you certainly can do so, but don't expend too many cycles on this. Instead, make sure you have good quality control processes to ensure that scope and quality are met before a task is marked complete and make sure the right people are assigned to the right tasks. One final note about task progress: There are certainly unknown elements that could derail this task's progress. Patty could get sick or win the lottery and not come back to work. Patty could run into problems with the last segment of code and not be able to complete it on time or she may have to expend twice the number of hours to get it completed on time. There are a lot of variables with some types of tasks and you can't account for all of them. However, your risk planning should have addressed the known risks, especially if Patty is the only person who can write that particular code (resource risk), and if that task is on the critical path (schedule and project risk).
10.3.4. Managing VarianceWhen you discover a variance in your project (plan versus actual), there are really only four possible courses of action. You can choose to ignore the variance if it's minor or a one-time issue. You can take action to address the issue, or you can modify the project plan to accommodate the issue. Finally, you can choose to cancel the project in response to unacceptable levels of variance. Since so much of managing your project is managing variance, we're going to discuss this in more detail in the upcoming section titled "Managing Project Change." 10.3.5. Managing Related PlansWhether your training, communication, quality testing, or operational transfer plans are internal or external to your project plan (tasks within your project or checkpoints that refer to external plans), you need to keep track of the timelines and deliverables related to these plans. Two common complaints about IT projects is the lack of communication and the lack of attention paid to training plans. Both of these are easily addressed through your project plan, which we discussed earlier in the book. During the implementation/management phase of the project work, it's important for the IT project manager to monitor the coordination of these plans. You can improve both the perception and the reality of project success by communicating effectively at appropriate intervals. You can also help by making sure that changes in this project are mapped with these related (or external) plans so that changes in one will be appropriately reflected in the other. Timing is everything and that's certainly true with these types of related plans, so make sure that you (or someone on your team) is managing or watching over the interaction between your IT project plan and these related plans. It's often helpful to delegate this to someone on your team and it can be set up as a recurring task within the project plan to ensure these plans remain visible. Also be sure to address the impact of changes in your project plan on these external plans. You should be aware of what the impact will be on the external plans if several key project tasks are delayed and be sure to coordinate with these external plans so things don't get out of sync.
|
EAN: 2147483647
Pages: 166