This action might not be possible to undo. Are you sure you want to continue?
10 open source projects worth checking out Why critical path is critical to project management Use this process to estimate a project’s effort hours 10 techniques for gathering requirements Five tips for building a Work Breakdown Structure Make Work Breakdown Structure easier with the materials you use Project management: Pin down how your client defines quality 10 ways to avoid stupid project estimates Facilitate a meeting to define what success looks like for your project 10 ways to avoid mistakes during project development Use a pilot project to confirm estimates and lessen risks Mining project requirements—techniques to use before and after an interview Use prototyping to visualize project requirements 10 best practices for successful project management JAD sessions will speed up the project definition process Don’t fall prey to these false project requirements 10 ways to avoid stupid project estimates 10 ways to overcome resistance to project collaboration software Categorize high-level requirements into use case titles for better project A four-step prescription for writing better project plans 1 3 5 6 8 9 10 11 14 18 21 22 24 25 29 31 32 35 37 40
During the Project
10 ways to get a slipping project back on track 10 signs that your project is about to be cut Sustain and broaden customer focus outside of your projects Create and sustain a customer focus within projects 10 tips for meeting IT project deadlines 10 reasons why use cases are indispensable to your software development project 42 45 48 51 53 55
10+ project management mistakes (and what you can learn from them) 58 10+ things that can send an IT project off the rails 10 signs that you aren’t cut out to be a project manager 10 ways to effectively estimate and control project costs Top five reasons organizations fail at project management Beware of when “completed” activities aren’t really completed See effect of dependent risk by using a decision tree Apply work breakdown structure techniques to organize a program Supervise larger projects with a schedule management plan Look at four ways to set precedence relationships in your schedule Create a risk contingency budget using Expected Monetary Value Use a Fishbone Diagram to attack complex problems A primer on projects, programs, and portfolios Four tips for using metrics on your project Manage project time requirements with these methods Don’t wait to address performance problems on a project 61 63 65 69 71 72 74 75 77 79 80 82 84 86 88
techniques to use before and after an interview Ensure requirements are tracked throughout a project Use gate reviews to validate that you’re ready for the next phase of your project Three warning signs that your project is doomed Use the tradeoff matrix to foster collaboration in agile projects 10 things you should do near the end of a project 90 99 101 102 104 107 109 Agile project management tips Four variants of agile development methods Five agile project management migration tips Adaptive Project Framework: A new level of agile development Agile reporting methods for project managers Agile drivers for new project management tools Get an overview of the Scrum agile project approach Take positive risks to gain project benefits Find errors as early as possible on your project Inadequate quality management will result in project problems 111 115 118 121 124 126 128 129 131 .Master these 10 processes to sharpen your project management skills Mining project requirements .
Microsoft Project 2007 Add a custom report in Microsoft Project 2007 Add the Late Indicator tool in Microsoft Project 2007 Identify slipping and unstarted tasks with Microsoft Project filters Importing a vendor’s Excel schedule into Microsoft Project Identify late tasks with this custom Microsoft Project filter Scheduling project uncertainty with LiquidPlanner Considerations when integrating Microsoft Project and PPM solutions Build a customized Gantt chart view in Microsoft Project Build milestone charts faster with MindView 3 Business software How to use project data to develop a better estimation matrix Export project data for future effort estimation View the critical path in Microsoft Project Using a fixed duration task type in Microsoft Project Confirm your Microsoft Project Schedule is ready for EVM 133 135 138 140 143 147 150 152 155 158 160 163 166 168 .
Project pre-planning 1 .
10 open source projects worth checking out
How many open source projects are out there? Thousands upon thousands. And out of all those projects, how many are worth paying attention to? Thousands? Hundreds? If you remove the usual suspects (Linux, Apache, MySQL, PHP, GIMP, OpenOffice, Firefox, etc.), you can really start paring down the list. Here are 10 open source projects you might never have heard of — but really should check out. open source project. The elgg social networking platform offers profiles, notifications, groups, blogs, embedded media, files, microblogging, pages, external pages, and more. If you’re looking for a means to improve you company morale but don’t want users logging on to Facebook or MySpace, give this open source social networking platform a try.
Magento is one serious ecommerce tool. This isn’t your Drupal-ecommerce-module-level ecommerce tool — this one can stand up with the big boy platforms (and knock some of them down). Magento features marketing/promotion tools, site management, analytics and reporting, catalog management, catalog browsing, product browsing, mobile solutions, checkout, shipping, payment, and more. Magento was voted “Best New Project” on SourceForge (2008) for a reason. With community and enterprise editions, there is a solution for everyone. NOTE: While the Community edition is free (and is missing numerous features), the Enterprise edition does have a price tag (and a steep one at that: $8,900 per year!)
Are you looking for your next ERP application? If so, do not overlook OpenBravo. This tool is a small-footprint powerhouse that includes integrated accounting, sales/ CRM, procurement, inventory, production, and project/ service management. OpenBravo also features singleinstance to multiple tenants, organizations, localizations, and warehouses. It is every ERP tool you will need in one open source toolbox. If just want to evaluate it, you can try a virtual machine with OpenBravo. But to download a package, you will have to walk through a questionnaire. Warning: Someone might try to sell you something!
OpenNMS should have no problem winning you over. This tool is a serious network management platform. OpenNMS offers three main areas: service polling, data collection, and event/notification management. Its feature list is pretty impressive and includes node listing, searches, outages, path outages, events, alarms, surveillance, and distributed status. If you need to be sold on this product, hop on over to the OpenNMS Demo page (user/password “demo”) to see what this tool is all about. OpenNMS will run on Linux, Solaris, OS X, and Windows (2000, XP, 2003).
DotProject is a Web-based project management tool that offers the features you’d expect — and more. The feature list includes user management, trouble-ticket system (integrated voxel.net Ticketsmith), client/company management, project listings, hierarchical task lists, file repository, contact lists, calendar, forum, and a permission system. What stands out with dotProject is its clean and simple user interface.
Heartbeat is the heart of the Linux High Availability project. It’s the piece of the HA project that performs death-of-node detection, communications, and cluster management. Heartbeat is a daemon that provides the cluster infrastructure so that peer machines will know the
Elgg is an open source social networking platform that powers numerous social networking sites. As many companies move to offer in-house social networking, you would do well to invest a bit of time and effort into this
status of all cluster resources. Of course, Heartbeat isn’t much good without a Cluster Resource Manager (CRM). Since Hearbeat is a piece of the HA project, you can be sure there is a CRM tool ready. Although Heartbeat ships with a minimal CRM, a new project was spun off, Pacemaker, that serves as the CRM for the Heartbeat foundation. If you are looking for an open source clustering solution, this might be the ticket.
the Open Source edition. With the Eucalyptus cloud computing solution, you are getting more than just the means to serve up cloud apps — you can also control both the network and the storage infrastructure. Eucalyptus works with Ubuntu, OpenSuSE, Debian, and CentOS and supports both Xen and KVM hypervisors.
10: Google Web Toolkit
Enomoly offers a cloud computing solution for any size environment. If you want to get to the source, however, you have to use the Community edition. This version is for SMBs and smaller enterprise use. With this browserbased management tool, you can design, deploy, and manage virtual applications within a cloud environment. You can plan and simplify deployments and automate virtual machine scaling and load-balancing. If you are a developer, you will appreciate the fact that Enomoly includes links to both its core APIs.
Nuxeo is an outstanding document management system that is incredibly feature rich and simple to install. Nuxeo has so many features, the best way for you to see them all is to go to the Nuxeo Feature List page. With the Nuxeo document management system, users can work either on- or offline (working offline requires an uploading of content). Users can simply drag and drop content from desktop to Web browser for content capture. It doesn’t get much easier. Nuxeo is also offered in a cloud computing edition, which eliminates the need for storage, hardware infrastructure, or server availability. The cloud edition of Nuxeo was built with the Amazon AWS.
Eucalyptus is another entry in the open source cloud computing space. There are two versions of this solution: Open Source and Enterprise. Naturally, we are looking at
Why critical path is critical to project management
When I was a business analyst working on a human resource talent acquisition implementation, six weeks out from the launch date the project manager rushed us into a room and asked us to figure out the critical path. I had heard the term critical path before, but I didn’t really understand what it meant. I knew the project was critical to the HR organization and thought everything on the project was on a critical path. Project managers will be amused that we were trying to figure out the critical path with six weeks before launch rather than prior to project execution. In hindsight, the project manager should’ve known the critical path earlier and been monitoring the schedule’s progress. I still find it puzzling that the project manager asked a bunch of business and system analysts to determine the project’s critical path. It wasn’t until I shifted my career into project management that I gained a better understanding of the critical path and its impact to a project. The Project Management Body of Knowledge (PMBOK) defines the critical path as “the sequence of schedule activities that determines the duration of the project.” Project managers can also apply the critical path methodology technique to “determine the amount of float on various logical network paths in the project schedule network to determine the minimum total project duration.” If you’re just as confused by the PMBOK speak as I was, let me restate it in a way that’s easier to understand. The critical path is simply all the tasks that determine the end date in your project schedule. If one of those tasks is late by one day, then your project end date will be extended by one day. Oftentimes, there will be tasks that are not on the critical path; this is due to the slack in the project schedule. If you refer to your current schedule, you can examine the Gantt chart and quickly identify the tasks that have some float compared to the tasks that have no slack. Slack is the amount of time a task can be delayed without impacting the start date of a subsequent task. The critical path methodology is simply a technique to identify all the tasks that will directly impact the project end date. Figure A depicts a Gantt chart with a set of tasks on the critical path.
Critical path in Microsoft Project
In Figure A, there are five tasks in the project schedule and Task 4 is not on the project’s critical path. If Task 1, 2, 3, or 5 is delayed, then the entire project will be delayed. If Task 4 is delayed, it has seven days of free slack before it will start having an impact on the schedule. Since Task 5 is three days in duration, Task 4 could have an actual duration of 10 days before it becomes part of the project’s critical path. If it exceeds 11 days, Task 4 will create a new critical path.
Critical path explained
Critical path in Microsoft Project
you can quickly identify and monitor the tasks on the project’s critical path. and detailed scheduling metrics along the critical path. you can see the adjustments in the critical path. Figure B Critical path free slack 4 . Task 5 has 7 days of slack and is not included on the critical path. Tools are invented for a reason and. Critical path and network sensitivity If you want to learn about the critical path and network sensitivity. The article features the sample Microsoft Project file if you want to experiment with adjusting the critical path. read my article on Network Sensitivity and the Critical Path. Figure B depicts the free slack in Microsoft Project. fortunately. By switching to different views and formatting the Gantt charts. By increasing or decreasing duration on specific tasks.I’ll admit I’m reluctant to create a network diagram and start the forward and backward pass mechanics. All the tasks on the critical path have zero slack in their schedule and that’s why these tasks drive the end date. Critical path free slack In my next column. Microsoft Project can support forecasting. what-if analysis. I’ll show you how to identify the critical path in Microsoft Project and use the different views to monitor and track the critical path.
you must estimate effort hours first. Make sure it seems reasonable to you and that you are prepared to defend it. On real projects. and the more time that is needed. training specialists. legal. There are many techniques you can use to estimate effort including task decomposition (Work Breakdown Structure). 75%. it is important to document all the assumptions you are making along with the estimate. For instance. 1: Determine how accurate your estimate needs to be. 4: Consider rework (optional). 5 . Once you understand the effort that’s required. Of the three. the project management time would be 150 hours. I call this being able to take some initial pushback from your manager and sponsor. If you have done this project many times before. the more detail is needed. Contingency is used to reflect the uncertainty or risk associated with the estimate. all project deliverables would be correct the first time.000 hours (7 . etc. 3: Add specialist resource hours. perhaps your contingency would be very small — perhaps 5%. and cost. Workplans that do not consider rework can easily end up underestimating the total effort involved with completing deliverables. If you are asked for a rough order of magnitude (ROM) estimate (-25% . If you’re asked to estimate work that is not well defined.800 hours) is needed. In a perfect world.8 people). 8: Review and adjust as necessary. and then you can estimate labor and non-labor costs. if a project estimate is 12. you might be able to complete the work quickly. and with a minimum amount of detail. If your estimate doesn’t look right. You will never know all the details of a project for certain. On the other hand. the more accurate the estimate.+75%). Use the following process to estimate the total effort required for your project: 5: Add project management time. you can assign resources to determine how long the project will take (duration). duration. analogy. Typically. and you don’t feel comfortable to defend it. This type of disciplined approach to estimating will help you to create as accurate an estimate as possible given the time and resources available to you. expert opinion. you might need to spend quite a bit more time and understand the work at a low level of detail. 6: Add contingency hours. go back and make adjustments to your estimating assumptions to better reflect reality. In general. etc. add 15% of the effort hours for project management. If the project estimate is 1. 9: Document all assumptions. administrative.Use this process to estimate a project’s effort hours There are three early estimates that are needed for a project: effort. if you must provide an accurate estimate within 10%. that usually is not the case. Pert. Make sure you include hours for part-time and specialty resources. the estimate seems obviously high or low. Therefore. you may add 50%. Sometimes when you add up all the components.000 hours. For instance. work to do on the estimate. this could include freelance people. If your sponsor thinks the estimate is too high. you have more 2: Create the initial estimate of effort hours for each activity and for the entire project. procurement. This is the effort required to successfully and proactively manage a project. a full-time project manager (1. or more to reflect the uncertainty. at a high-level. 7: Calculate the total effort by adding up all the detailed work components.
These interviews work well when everyone is at the same level or has the same role. you might also want to participate in the actual 4: Joint application development (JAD) JAD sessions are similar to general facilitated sessions. You show this to the client. Use cases may be easier for the users to articulate. However. 6 . 8: Following people around This technique is especially helpful when gathering information on current processes. The discussion should be planned out ahead of time based on the type of requirements you’re looking for. and they are good tools to gather requirements from stakeholders in remote locations or those who will have only minor input into the overall requirements. 2: Group interviews Group interviews are similar to the one-on-one interview. You change the application and cycle around with the client again. the group typically stays in the session until the session objectives are completed. You may need to watch them perform their job before you can understand the entire picture. The “elicitation” step is where the requirements are first gathered from the client. you bring a larger group (five or more) together for a common purpose. Group interviews require more preparation and more formality to get the information you want from all the participants. Many techniques are available for gathering requirements.10 techniques for gathering requirements It’s difficult to build a solution if you don’t know the requirements (in spite of the fact that many teams still try to do it today). For a requirements JAD session. and in many cases. although the use cases may need to be distilled later into the more specific detailed requirements. Questionnaires can also be used when you have to gather input from dozens. for instance. 3: Facilitated sessions In a facilitated session. you gather preliminary requirements that you use to build an initial version of the solution — a prototype. or thousands of people. 5: Questionnaires Questionnaires are much more informal. 1: One-on-one interviews The most common technique for gathering requirements is to sit down with the clients and ask them what they need. This repetitive process continues until the product meets the critical mass of business needs or for an agreed number of iterations. that some people have their work routine down to such a habit that they have a hard time explaining what they do or why. The stories include people (actors) and describe how the solution works from a user perspective. In some cases. In this approach. you are trying to gather a set of common requirements from the group in a faster manner than if you were to interview each of them separately. you need multiple techniques to gain a complete picture from a diverse set of clients and stakeholders. Here’s a look at some of the approaches you can take. 6: Prototyping Prototyping is a relatively modern technique for gathering requirements. the participants stay in session until a complete set of requirements is documented and agreed to. In this case. You can uncover a richer set of requirements in a shorter period of time if you can keep the group focused. hundreds. except that more than one person is being interviewed — usually two to four. There are many good ways to plan the interview. who then gives you additional requirements. You may find. but generally you want to ask open-ended questions to get the interviewee to start talking and then ask probing questions to uncover requirements. 7: Use cases Use cases are basically stories that describe how discrete processes work. Each has value in certain circumstances.
work process to get a hands-on feel for how the business function works today.
9: Request for proposals (RFPs)
If you are a vendor, you may receive requirements through an RFP. This list of requirements is there for you to compare against your own capabilities to determine how close a match you are to the client’s needs.
On some projects, the requirements are not “uncovered” as much as they are “discovered.” In other words, the solution is brand new and needs to be created as a set of ideas that people can agree to. In this type of project, simple brainstorming may be the starting point. The appropriate subject matter experts get into a room and start creatively brainstorming what the solution might look like. After all the ideas are generated, the participants prioritize the ones they think are the best for this solution. The resulting consensus of best ideas is used for the initial requirements.
Five tips for building a Work Breakdown Structure
A Work Breakdown Structure (WBS) is the best way to understand the detailed work of the project when you have to build a schedule from scratch. It’s used to break the project down into the major phases, deliverables, and work components that will be built by the project. These work components can then be broken down into the activities that are required to build them. The WBS is not the same as the final schedule (which requires sequencing, resources, estimated effort, estimated duration, etc.). Here are five tips to keep in mind when building your WBS:
3: Break activities into two or more detailed activities
I’ve seen teams that break one activity in the WBS into only one activity at the next level. In my opinion, this doesn’t make sense because then the detailed activity represents the same work as the prior summary activity. This doesn’t buy you anything.
4: Make the final detailed activities action oriented
The detailed activities on your WBS (the ones that are not broken down further) are ultimately moved to your schedule. For that reason, it’s easier if the detailed activities in your WBS are action oriented — just as activities in your schedule would be. For example, instead of describing a detailed WBS activity as “meeting,” you should state it as “schedule a weekly meeting.” Instead of having a WBS detailed activity for “Testing Plan,” you should state it instead as “Create Testing Plan.” In this way, the detailed activities can be moved to the schedule with a minimum of wording changes.
1: Create a WBS dictionary for large projects
Normally you wouldn’t need a WBS dictionary, but if your WBS has hundreds (or thousands) of detailed activities, there may just be too much to keep track of by hand. In this case, it might make sense to place all of the important information in a WBS dictionary. The dictionary helps keep track of all of the summary and detailed activities, including a short description, the WBS numeric identifier (1.1, 1.1.1, 1.1.2, etc.) and the estimated effort. If you enter your WBS dictionary into a specialized tool, the tool can also help to keep track of changes to the WBS as well.
5: Don’t place requirements on the WBS
If you place a deliverable on your WBS, you can break this deliverable down into the activities that are required to create it. You don’t break a deliverable down into the requirements that describe it. Requirements do not belong on a WBS. Only deliverables and activities belong on the WBS. By using these five techniques, you will save you time and rework on your next WBS.
2: Use the summary activities as milestones
Your WBS should contain both detailed and summary activities. (A summary activity is one that is broken down further; a detailed activity is one that is not broken down further.) Although a schedule usually includes only detailed activities, it makes sense to include the summary activities as milestones (i.e., markers signifying that a deliverable or set of deliverables is complete). A summary activity can be used as a milestone since it would indicate that all of the underlying detailed work has been completed.
Make Work Breakdown Structure easier with the materials you use
Almost all project schedules are built using a Work Breakdown Structure (WBS). When you’re building a complex schedule, you don’t sit down and identify fall of the activities starting with the first one and ending with the lastYou probably first enter your high-level work, then come back later and start filling in the detailed work. This is basically the WBS technique. If the project manager is the only person creating the schedule, it’s very likely that the WBS will be created at the same time the work is entered into your project management scheduling tool. However, in many cases the project manager doesn’t know enough to lay out the entire schedule from scratch. In this case, a small group of people may be required to complete the WBS. When you’re creating a WBS in a group setting, it may be best to use Post It notes and a blank wall to create the first draft of their Work Breakdown Structure. This technique is very easy. After you get the appropriate people into the same room (project team members and clients who have the expertise to build the WBS), you start to build it. You can start off by writing the names of the major deliverables on Post IT notes, one deliverable per sheet. Make sure the attendees agree on the major deliverables to begin with. If any of the deliverables are very large, you can create new notes that describe the deliverable at the lower level of individual work products. These work products are arranged under the higher-level deliverable. The deliverable needs to be identified at a level low enough that you understand what it takes to build it. In general, two levels should be enough to identify your deliverables. One level is typical. Next, for each deliverable, describe the activities that must take place to complete it. Each activity goes on a separate note. These activities are arranged under the specific deliverable they refer to. If you have a sense for the order that the activities need to be completed, you can arrange the notes sequentially. However, this isn’t vital at this point. The important thing is to identify all the work. Look at the activities that are required to build each deliverable (or work product) and estimate the work associated with each activity. If the effort associated with an activity is larger than 80 hours (or whatever high-level threshold you set), you would break that activity into a set of smaller activities. Each of these activities is represented by new Post It notes under the higher-level activity (which now becomes a summary activity). Continue with this process until the work required to complete all of the deliverables are defined, as best you know at that point. Some simple deliverables may take one or two levels of work breakdown. Others may take three, four, or more. The advantage of this approach is that your team can actually see the work and they can help ensure all the work is identified to complete the project. The Post It notes also give you the ability to easily move things around. If you add an activity and then decide to remove it, you just pick up the sticky sheet. Likewise, if a deliverable or group of activities is in the wrong place, you just move the sticky sheets to where they need to be. When you’re all done, you can enter the detailed work activities into your workplan management tool. Remember that the WBS is not the same as the schedule. The WBS is only the technique you use to understand the work at a low level. When the WBS is completed you can continue to build your schedule by sequencing the activities, assigning resources, estimating costs and duration, etc.
these end up being detailed quality requirements and they’re captured along with all of the other project requirements. People sometimes ask where this information gets documented. 10 . Your customer may only tell you that you should build a “good quality solution” or you should build a solution with an “acceptable level of quality. It’s easy . But what the heck does that mean?” The customer needs to state that the project solution needs to be: Reliable Easy to use Easy to maintain when completed Available when needed Flexible for future needs Intuitive / easy to understand Secure Minimally defective (Doesn’t have to be perfect) Once you’ve gotten that far. Let’s say that the customer thinks that a good quality solution needs to be “secure.Project management: Pin down how your client defines quality A good definition of quality management is “to first understand the expectations of your customer in terms of quality and then put a proactive plan in place to meet that level of quality.usually by accident.” The first part of this definition can be the toughest . Most project teams focus requirements on understanding features and functions. If you focus on features and functions.understanding what quality means to your customer. many of the quality requirements may come out as well . Most project teams don’t make it a point to capture all of their quality requirements. But if your team is trying to practice formal quality management. this means The solution should be place in a secure room with password access Only authorized people can login The password must change every thirty days There will be role-based security so people can only see data that is consistent with their roles. you should have a discussion with your clients that focuses on the broader and more specific set of quality requirements. you need to help the customer drill down further.” Your response to that should be “Great.” Further probing might reveal that for the customer.
or maybe don’t have a problem at all. a deep dive into this topic would be an entire article (or two) in itself.10 ways to avoid stupid project estimates Projects run on estimates. and you get a reasonable taskby-task break down of the two days’ work. This also provides 5: Bracket the work This is for those who just can’t come up with a time estimate for the work. 4: Measure Okay. but some people continue to fall for it. If they can’t. more manageable. the estimates of others are probably all you have to work with. just start capturing expected date versus actual delivery date. perhaps they should be thinking about their estimate some more before you start relying on their figures. How long does it usually take? You don’t know unless you track this information. past performance can be an indicator of the future. It would not be the first time I’ve seen a discussion with developers expose previously undiscovered project tasks. you will surely come to rely on estimates of others. at least you will know that they gave it some thought. but challenge the developer or development team to explain why they think it will take so long. Overall. Unless you’re in one of a small handful of roles. Don’t be surprised if the estimate actually goes up. I can’t tell you the number of times I’ve seen developers give an estimate of two days and actually take four. But if you don’t have a clue where to start. because there was probably four days’ worth of work to begin with. two days may be right on the mark. try helping them break down their work into smaller. a great opportunity to assess their assumptions. If they can justify their estimate. Left hidden. This also ties into the history suggestion above. You might be surprised by the patterns that develop 2: Ask for details (proof) Learn the justification for an estimate. you really don’t know whether you have a big problem -. There’s nothing wrong with that. Here are a few ideas to help you see this aspect of estimating more clearly -. If it has taken twice as long as the estimate the last five times an estimate was given. First. there isn’t a great deal of information on getting better estimates from others. even if it’s just to frame your own estimates. Vetting the estimates you get today 1: Let history be your guide It is true: History does repeat itself. Ask questions. And if you’re a project manager. Unfortunately. 11 . 3: Challenge the numbers Push back. you know your developers are always missing their estimates. you can’t improve it if you don’t measure it. tasks. Project managers seem to do this pretty naturally. As much discussion as there is on the estimation process. You either have to provide estimates of things such as how much effort your task will require or you will need such information from others. project estimates are only as good as the individual estimates associated with the component tasks. it may be time to worry. Unlike the stock market. Metrics also go a long way toward improving estimates. but by how much? If you aren’t measuring it. why would anyone think the estimate will hit this time? Beats me.and help you avoid leading your project astray before it ever starts. Like any process. But if your developers just shrug their shoulders. While not great news. The problem is that I also see people in meetings repeatedly believing them. If you ask why they think it will take two days. those tasks would have surely destroyed the timeline when they came to the surface and jumped onto the critical path. it’s still better to find out about this sooner rather than later.
If you create the situation where it is better to beat an estimate than simply meet it. An objective third party is exactly what you need to free you of your bias and give you a clearer view of reality. While this is efficient. throw out the highest and the lowest. a second opinion may be in order. Generally speaking.a lead developer.Next. and he wrinkles his nose at it. Your folks will be able to take it from there. That is certainly good to know. or if the team has a bad track record for this sort of thing. you may have learned that certain groups always underestimate by 25 percent. When working with a team. it’s one in which those providing estimates feel safe in providing accurate information as opposed to providing the information they believe supervisors want to hear. Of course. Celebrate when estimates are hit. you will create an incentive for overestimating. it will take…” comes from. especially if there is a wide variance in the estimates of the individual team members. Help them identify patterns in how they estimate and challenge them to find the root cause of their bad estimates. it must also be one in which 12 . you should be challenging and asking for details throughout this process. you may find it useful to use a simple bracketing technique to help the person zero in on the figure that is appropriate. Improving future estimates 8: Give feedback You have captured task estimates. so provide them the tools and a few suggestions. but what is the right culture? Certainly. you probably have as good a number as you can expect. for example. 7: Remember that two heads are better than one Run your figures past someone who might have experience with your type of project. but don’t let the value stop there. you may have some more digging to do. When was the last time “all went well”? There’s nothing wrong with qualifying an estimate. but adding an unrealistic assumption as a way to give a bad estimate only hurts the project. Provide feedback to the team members. not that a task estimate is too long. they say you should get several estimates. “Is five days enough time?” “Can you do it in less than 10?” Continue in this fashion until you get a figure that everyone is comfortable with. people really do want to do a good job. Be serious. 9: Reward and penalize Penalize the bad estimate. If you have reason to suspect an estimate may be off. From this. When estimates are missed. 10: Develop a culture Using the correct rewards and penalties goes a long way toward establishing the right culture. 6: Get a second opinion When you’re hiring a builder. Perhaps they are telling you what you want to hear. and you have tracked actual. If everyone is of a like mind. it may add some risk to the accuracy of any estimate you receive. and then go with the one in the middle. a blatant falsehood to avoid having to face some development reality. There might be something to that approach. you’re probably getting your estimates from the team’s point person -. you don’t need to tar and feather the offenders. Seek an informal read from other members of the team. However. If this person is not on your project. That is where the “If all goes well. You may be getting the result of a faulty team consensus. but you can treat it as a remedial education opportunity (the very act of which will be a penalty of sorts). When estimates are shortened. or an estimate flawed by an innocent miscommunication. Perhaps you’re a sucker for good news. all the better. it’s generally because that shorter number is what’s expected. You want to drive toward behaviors that give better estimates. If you run the team estimate past an individual developer. Be careful about rewarding beating an estimate differently from hitting it.
everyone strives to improve the quality of their estimates and the notion of providing a bad estimate is as bad as providing bad program code. Managers must also respect those providing them with information, once those people have proven themselves. Ultimately, if you can get peer pressure to “manage” the estimates, your job will become considerably easier.
Improve your project... one estimate at a time
You can’t run a project well with bad estimates, any more than you can build a house with faulty bricks or lumber. Fortunately, you don’t need to do everything yourself (nor could you) to get estimates you can trust. Exercising the simple ideas above will help you filter out the bad numbers you get today, improve the numbers you get tomorrow, and generally make your life a whole lot better -- at least as far as your project is concerned.
Facilitate a meeting to define what success looks like for your project
Although most projects start enthusiastically, optimism fades quickly unless an analysis and design team gets traction and learns where it is going. Working from a project charter, the team’s next step is defining typically, “What does success look like?” These high-level requirements help clarify the project’s vision and give the team a focus. Many business analysts employ group facilitation to elicit these requirements. This blog post summarizes some of the steps you might follow in facilitating such a meeting. the meeting armed with the first three success factors. Through facilitation, you enable the fourth.
Facilitation as a tool
Facilitated group meetings generate positive outcomes in several dimensions. First, consider the axiom, “The whole is greater than the sum of the parts.” In my experience, a facilitated meeting routinely generates more high-quality ideas than would be revealed by one-on-one interviews. While “designed by committee” is sometimes derided, all requirements are subject to scrutiny eventually anyway. There is significant value in distilling and refining the team’s smorgasbord of requirements early in the project. Facilitated meetings create value beyond the requirements. Even in the first meeting, you will witness the formation of a functioning team. From the ideas suggested by individual team members, adjustments, clarifications, compromises, and consensus emerge. Although it may take three or four meetings, a working team emerges and produces valuable results.
The importance of “group think”
Long a mainstay of business analysis, one-on-one interviews with stakeholders is a standard business analysis tool. Typically, each stakeholder represents to you the interests of his or her own business unit and measures the project by what the unit may gain or lose. Accumulated, these one-on-one interviews make me think of the ancient Indian story of “The Elephant and the Seven Blind Men.” Perhaps you remember the story. One blind man judged the elephant to be a large snake because of its trunk. Another claimed the elephant was a tree because of its leg, and so on. Is there method to develop consensus among opinionated individuals? I’ve found facilitated meetings to be useful. How important is the “group think” that comes from facilitated meetings? In the elephant story, a revelation comes to the blind men as a wise man affirms their perceptions and helps them understand each other’s perspectives. In a facilitated meeting, you help the team members recognize their unique perspectives, reveal mutual interests, and distill common agreement. What makes this process work? In his recent book The Wisdom of Crowds, James Surowiecki indicates that a successful group needs a diversity of opinion, independent perspectives, decentralized governance, and a good method for aggregating opinions. Stakeholders typically arrive at
Building an effective analysis team
Who should attend the team meetings? At a minimum, you need the stakeholders or their designees. The team should also include the project manager, the technical project manager, and a representative of the sponsor. If the project is expected to affect numerous business units, find someone with the experience to plan and execute communications. The team will also need someone in an administrative role to take meeting notes and to handle logistical details. If asked, the project sponsor may suggest a person for this role. Although the project sponsor may have already set the team’s membership, you should consider the functional experience of those who were tapped to participate.
Talk with others who may be affected by the system. The project sponsor and the current team members are good resources for the names of others who should be considered for team membership. Will the membership adequately represent the functional areas touched by the new system? Is each team member an expert in a functional area? The project manager may be a resource for estimating the breadth and depth of the team’s experience. He or she may also know each individual’s work style and work ethic. If you feel strongly that the team needs more (or different) resources, make your case with the project sponsor. Consider asking the sponsor, “Who else could help this project succeed?”
expected meeting time exceeds two hours, schedule a short break in the middle. When you set a meeting date and an agenda, send an e-mail to the participants. Copy the project sponsor. Attach the agenda and project charter. In your message, set a tone of enthusiasm and excitement. Also, promise to start and end the meeting on time. Encourage the team members to come prepared to offer and discuss requirements. Indicate you will be calling each person for a brief chat over the next day or so. Follow up on your commitment to call. Briefly introduce yourself and explain the reason you are calling. Ask if they have a few minutes to talk about the project. If you called at a bad time, ask them to offer a better time to talk. Asking about their interests in the project is a good way to build rapport and keep the phone call short. Take notes as you listen. Thank them for their time and tell them you look forward to seeing them at the meeting. Your phone call reminds them of the meeting and its importance, raises their interest level, and introduces you in a positive way. Before the meeting, familiarize yourself with the topic area. Study the project charter and any supporting materials. Have a good understanding of the jargon the team is likely to use. You don’t have to be an expert, but you have to understand the business concepts and lingo the team will use. Consider meeting with a functional expert. As a final step, gather the materials you need. Find a few
The facilitation cycle — setting up
There are three major steps in successfully facilitating a meeting: setup, execution, and follow-up. Start preparations by finding a common time and place the team members can meet. Check schedules to make sure everyone has enough time to get to your meeting. Leave some unscheduled buffer after your meeting as well. This buffer gives some team members time to linger and ask questions or discuss an idea. Reserve a convenient, comfortable meeting room with adequate table space. Make sure the room has an adequate supply of flip chart paper and a stable flip chart stand. You’ll also need two vacant walls on which you can hang flip chart pages. As any project manager knows, there is no such thing as an unwritten plan. This wisdom also applies to meeting agendas. Write the agenda to include a five- or 10-minute introduction to the project and use the project charter as a resource. There may be some new faces among the team members. Allocate time for brief introductions from attendees. Although the remainder of the meeting will be requirements work time, leave five minutes or so at the end for a “check out” — a chance for participants to voice an opinion about the meeting or the process. If the
narrow-tip, black felt-tip pens. Make sure they produce clear lines and don’t bleed through the flip chart paper. If you don’t have any self-stick flip chart pads, bring along masking tape for hanging flip chart paper on the meeting room walls. Bring a few extra ink pens and pencils in case team members need them.
Arrive about 10 minutes before the meeting starts. Arrange chairs around the table to make the attendees
” There is also a chance someone may wander wildly beyond the scope of project. enthusiasm. If you got it completely wrong. encourage. “What are the limitations with the current system?” On the flip chart pages on the wall. you can get them started by asking. and ideas of the team into a workable set of high-level requirements. It helps to smile or nod when someone suggests an idea. and record. ask other team members to wrestle with it through leading questions — “How would that work in this business unit?” or “What do others think about that idea?” Stumbling blocks may arise in the discussion. If you haven’t written any new requirements after a few minutes. As the facilitator of this elicitation process. “It sounds like we need to explore this topic in the future. Even so. Hang several sheets of flip chart paper side by side on one wall. Promise to address the Parking Lot items at another meeting. Be careful to write clearly. and their role in the project. I’m wondering if we can make a note of that topic and discuss it in depth at a future meeting. Acknowledge the importance of the person’s idea and then ask the group to consider it in the context of the project mission and goals. think about how to summarize it. As you fill up each page. Set up the flip chart pad on the stand. During the introductions. At the beginning of the meeting. politely interrupt the discussion with. Have a marking pen handy. Ask the project manager or the administrative assistant to help by keeping an eye on the clock. As team members run out of suggestions. Place a few pens and pencils on the table. ask each person to introduce themselves by giving their name. strike it and write the correct text. If you feel you misunderstood what was said. The team members provide the content. I secretly write for myself a seating chart to help me connect names to faces. ask the contributor to clarify it. not technology. write your best summary and ask the contributor to affirm it or offer corrections. support. ask the contributor to restate or summarize it while you revise. As you hear what a team member is saying. clarify. Always avoid judging a contribution. new requirements will surface. a requirement can be defined as a feature the new system should have. Help the team avoid getting lost in a protracted discussion. so that each participant can read and understand what you wrote. Try to affirm every contributor and thereby raise the team’s enthusiasm and excitement. As they consider requirements. Number each item in the list. start them thinking about the high-level requirements for the new system. jot down a key phrase about each limitation and number it. Encourage them to think about people and process. put it there. you accept a mantle of responsibilities and constraints as you channel the energy. Instead. If a suggestion doesn’t make sense to you. the limitations you’ve written on the wall make easy targets. Encourage participants to expand and reframe ideas. Ask the project manager to review the project charter with the group. the business unit they represent. You may find that time slips away from you during the meeting. Introduce the main section of the agenda by providing a definition of requirements and their importance to the project. The team expects you to keep your commitment to end the 16 . translate.feel comfortable. Strive to enable. If team members seem stuck. write the topic on a blank sheet of flip chart paper and label it “Parking Lot. while you provide a structured medium to capture and hold it. For the purposes of this meeting. If the group believes it belongs in the Parking Lot. Since you can’t catch every word. but give it time for as long as it bears fruit. People improve their focus on a topic when they have had an introduction to it.” If the team agrees. the person filling the administrative assistant role can hang up the pages on an adjacent wall for all to see. Allocate a few minutes for questions and answers about the project.
ideas. you’ll give the team an opportunity to clarify. Tell them that you will type the lists and send them as an e-mail attachment in the next day or so. With Track Changes enabled in the word processor. At the next meeting. After carefully proofreading and revising these documents. Often. In facilitated meetings. Consolidate these changes with Track Changes enabled into your own document copy. What will you have accomplished? In a few intensive hours. As a side benefit. You will also introduce them to a place to store each type of artifact. the team will accomplished several goals. the other version is a “working” document that reflects your attempt to clarify cryptic Successful projects This document introduces facilitation as a strategy for eliciting requirements from a team of people. Don’t worry that some items on the flip charts are really business requirements. enable Track Changes in the working document and attach them both to an e-mail message you send to the team. and create forward motion in the requirements elicitation process. Acknowledge any contributor’s idea and make a note of anything that should be addressed. Encourage team members to add their own corrections and additions to the working document. or concerns about the project or the meeting. In closing the facilitation. Follow up Since you scheduled the meeting so that most team members don’t have to rush out. summary-level use cases. They will draft a set of requirements that the new system should satisfy. constraints. phrases and to give the reader a better understanding of the stated requirement. reframe. Sometimes knowing the order of ideas is helpful in understanding some detail or distilling a theme. Set a reasonable short-term deadline for their responses. You may overhear a key point or interesting perspective no one raised during the meeting. Eventually. interface features. user interface artifacts. 17 . Before you close the meeting. In future sessions. some may linger in the meeting room. you help team members develop trust in your leadership. The first one contains the exact words from the written pages. suggestions are apparent in the working document they send back to you. try to listen to these conversations. the team will have defined an impressive (but probably incomplete) picture of the new system. describe each document and its purpose. thank the team for their enthusiasm and ideas. In the e-mail. Consider numbering each flip chart page to record the sequence in which it was used. you’ll have the team validate or refute these suggestions for changes. the individual participants will began building an effective work group. While you are gathering the flip chart pages and restoring the room to its original state. I like to write two versions. By respecting their time. and so on. you will lead the team as they transform these high-level requirements into business rules. and revise these ideas. or system constraints. Each of these achievements significantly contributes to the success of your project. supplement. invite team members to briefly “check out” and state any thoughts. team members chat and familiarize themselves with each other. I encourage you to type the notes from the flip chart pages as soon as possible after the meeting. Ask each team member to review the documents. They will roughly define how the current system constrains business success.meeting on time.
) 2: Do your research first No matter how much you know. Unfortunately. In project development. it’s essential to communicate with other team members to avoid redundancies and to coordinate your work with theirs. Each challenge usually requires you to learn something new. and instant messaging with your peers. there is little excuse for mistakes made because you didn’t do the proper research in advance. instant messages. that roadmap is known as a project plan. you need to know how to get where you are going. You can spend the better part of a day reading and writing emails. Days or even weeks of programming time can be lost if the wrong path is taken. a project plan will help keep you from straying off course. But it is a necessary part of the development process. The trial-and-error method of learning may have been necessary and acceptable years ago. But with the resources available on the Internet today. The perfect tool for communicating and coordinating with others in a team environment has yet to be developed. you’ll encounter new challenges on an almost daily basis. The items listed here are specific to developers. each of these is far from perfect. but other IT roles can also benefit from many of them. do your homework.10 ways to avoid mistakes during project development You may have heard the phrase “Be proactive. 18 . 5: Communicate and coordinate with others If you are part of a team. and members of TechRepublic seem willing to honestly share their mistakes — even if somewhat embarrassing at times.” It’s certainly appropriate when discussing how to best deal with mistakes. is to prevent mistakes before they occur. But how exactly do you do that?” In this article. (The TechRepublic downloads library has a free communication plan template to get you started. of course. project status reports. Templates such as predefined forms can be useful since most of the work is already done in a standard format. writers. not reactive. but the editors. A mistake in a legal document can be an expensive exercise — one best avoided. participating in conference calls. Your project may also benefit from the use of a communication plan that ensures everyone involved — including customers and stakeholders — is kept apprised of key developments. The idea. and teleconferences are all ways to communicate and coordinate with others on the team. Whether done formally or informally. Emails. I will detail 10 real-world ways you can preempt mistakes during project development. 4: Follow standards and use templates There are good reasons why experienced professionals took the time to create and publish industry and company standards. 3: Have a plan You can’t know how to get to your destination without a roadmap. I am somewhat biased. 1: Learn from other’s mistakes Find experienced peers who are willing to share their mistakes and then learn from them. Before you tackle a problem or task. One of the better tools developed to share code is revision control software. For the sake of simplicity. When done the right way. Standards detail best practices and procedures learned over years of trial and error. I’ve lumped all errors into one category: mistakes. A standard EULA approved by your legal counsel is another good example of a template that can come in handy if you are developing application software.
you got it bad. For more on the virtues of using checklists. Careful and thorough testing will allow you to find those mistakes before your users can. Errors in the code are typically more expensive to correct when found near the end of the development process. test. poor design.” It didn’t happen very often. 8: Use checklists Before a commercial plane trip. Test as much as possible as early as possible. rushed through production. They are particularly useful when working with large systems and when a single person is responsible for multiple tasks. and incomplete documentation. Develop test data and a plan to test common calendar-based events like EOM processing and annual reporting. a list detailing the steps required for system turn-on will help avoid accomplishing tasks out of order and prevent errors of omission. Checklists can be used during various phases of the project development process. and the best way to do that is estimate them correctly up front. test… and carefully review your work There is a healthy level of paranoia about delivering errorfree work. detailed checklist. insufficient testing. They will undoubtedly use the system in ways you never dreamed of and find bugs you missed. see Leverage checklists to improve efficiency and client satisfaction. this is also a good place to use a checklist. Here are a few tips on creating realistic schedules.and triple-check your work. and upon arrival. failed testing. doubling my initial estimates came close to the actual time required. Double. He was much more realistic in his estimates. The result can be a system that doesn’t meet expectations and fails in one or more key areas. Ideally. You will likely have to modify the code to fit the new requirements. And. 7: Reuse proven code If you’re an experienced developer. inadequate analysis. Failure to allow enough time for each phase of the project can lead to missed requirements. rushed programming. the pilot and co-pilot are busy walking through a long.6: Allow enough time It was at Hughes Aircraft Company that I first heard the phrase “You want it bad . and he turned out to be right. I achieved the best results when I sat down with my supervisor and determined the time allotted for each major task in the project plan. external sources of code are available on the Internet that can be legally used for free or for a small fee. Not only will you reduce the risk of introducing new bugs. The last thing you need when facing a critical release date is to find a bug that should have been found months ago. Go blue and recycle this code whenever possible. I was overly optimistic in my estimates. All functionality and every single possible scenario should be thoroughly tested. That information was useful for developing project plan timelines. but you will eliminate the time wasted creating similar code and the subsequent testing required. yes. but when it did it was almost always made in reference to a part from a vendor that was badly needed. you want to complete each phase of the project on time. Proven code can be shared via plug-ins or libraries. Estimating the time needed to accomplish each phase of a project is difficult. It is all too easy for developers to overlook important items like system access when they are busy doing final testing and documentation. 9: Test. you should have built up a large code base over the years. 19 . For example. Good 10: Test again with a third party Find at least one experienced person who can be dedicated to the beta testing. As a rule of thumb. Share your code with others so they can reuse parts of it. You may need to develop a similar rule of thumb until you can more accurately estimate completion dates. but proven core code is a good foundation to build on.
I hope these proactive tips will help you avoid making an embarrassing mistake that becomes known to your boss. Once a bad piece of software is released or a system with a critical bug is turned on. I was but a young inexperienced pup when I accidentally deleted some system files on a Tandem PC. you might want to read Calvin Sun’s article 10 things you should do if you make a big mistake. This may be obvious. peers. It could have been a disaster. The final word One of the most important lessons I learned very early in my career is that a mistake isn’t a mistake until someone else knows about it. It can negatively affect your image and possibly damage your career. If you find yourself in that unenviable situation. and users. There is almost never anything to be gained by telling others you have done something really stupid. a company’s image can be tarnished for years to come. but you should keep unseen mistakes to yourself. I have always learned the most from my mistakes — but I prefer not making them in the first place. 20 . But I had enough sense and problem-solving skills to identify and copy over the missing files from another Tandem PC.Don’t overlook or rush this final quality assurance task. It’s typically your last chance to get it right. I have never told anyone until now about my near disaster.
I recommended that Matt conduct a short pilot project. but she said that the budget is very tight and that we would have to complete the work within our original estimate. identify a representative sample of databases — large. we may be substantially over budget. and so on. different departments. but it was still just a model. rather than having to start off with multiple efforts. document common procedures. “The estimate we prepared was just what my manager was looking for. “We are just starting the planning now. you may have to implement that unique solution repetitively in different offices. Focus and be successful on one project first. “What’s the quickest way to do that?” I noted that the quickest way isn’t always the best way. If the numbers are not close. and find the average effort and cost required. he was both happy and concerned. We haven’t done any conversions yet. When the pilot is complete. using a pilot project in such instances can give you the chance to: Document common procedures that can be utilized on the other similar efforts.” Matt replied. the pilot project makes great sense because he has a similar process that needs to be applied to hundreds of databases. he can be more confident that the entire project can be completed within the budget. different Web sites. you’ll sometimes find that the work efforts involved are similar 21 . Get a handle on the time and cost required to complete the entire effort. The solution Matt was beginning to see how he should proceed.” Mentor advice One of the common aspects of software development is that the solutions tend to be unique. “Migrate them to the new release and keep track of the effort and duration for each one. she has the budget approval to begin the work.” I told him. With proper planning. By properly planning the project. However.Use a pilot project to confirm estimates and lessen risks The dilemma I hadn’t talked to Matt since I helped him create an estimate for converting all our company’s databases to a new version.” he said. “I think the first thing we need to do is validate the estimates. he can select a representative sample of databases. If the actual effort is more than we estimated. In Matt’s case. For instance. transfer this subset of databases to the new release. “First. “That’s why I came to see you.” I asked when he would begin planning for the project.” Matt said.’ or repetitive. and small. When we caught up recently. “Fortunately. Matt will need to notify his manager so that appropriate actions can be taken before the project gets too far along. Then you’ll have some factual information to apply to the estimates — and you’ll know if you should break out the champagne or the aspirin. If the actual migrations are close to the estimates. medium. he can compare the actual averages with the estimated averages. Reduce the risk of project difficulties since you can look at what works well and what doesn’t before tackling the remaining work. I know we put together a nice estimate based on a model. That could put the entire project in jeopardy.
jargon develops to identify and describe its products and processes. make Learn the language As business specializes. Good preparation and good follow-up are critical factors in a successful interview.lack of privacy and phone interruption are examples. For that reason. or somewhere offsite. Unfortunately. try to meet outside the person’s office. Your local bookstore or library may have suitable books. Examine documentation. Locate each name in an organization chart. Schedule the meeting Hour-long interviews work well. set up a second meeting with the interviewee. 22 . If the interviewee has a packed meeting schedule or supervises people. Leave extra buffer at the end of an interview in case a little Prepare for the interview Choose the right business experts In the early stages of a project. don’t be shy. it helps to create a flowchart or context diagram showing the entities involved in a system domain and the nature of their involvement. certain no one can hear through the walls of the room where you meet. Early in the project. or interview people who can give you an overview of the process. If you must meet in the person’s office.the supervisor of someone you interview may feel jilted if you decide not to interview them. ask the sponsor for permission to interview representatives from these groups as well. learn existing systems. When you schedule the meeting. you have to choose a meeting place that enables the free flow of information. Enthusiasm for your questions often fades as the interviewee starts to think about his or her schedule. read books that describe the industry. deciding whom to interview is a challenge. there are many barriers to this flow -. Prepare for an interview by learning about that domain. you have to understand the language he or she will use. you may think a longer meeting is best. leave enough time buffers before and after your interview for the interviewee to travel between meetings. Be mindful of politics -. and consider their title and functional role. To become familiar with these terms and concepts. ask that they “busy” their calls. You should be able to identify the domain inputs and outputs. If privacy is a potential issue. In order for you to understand the interviewee. There are many sources for this understanding. time is needed to finish up. If you don’t feel an hour is enough time. Conducting a good interview can be a daunting task -. Consider using a corporate meeting room. and understand the processes within it. or has a reputation for making people uncomfortable.particularly if you are interviewing a stakeholder who holds a high position in the organization. Are there people above and below them in the organizational hierarchy that you should also interview? Does the business problem affect vendors or customers? If so. I’ve conducted some excellent interviews over lunch in a noisy place.Mining project requirements -. Pick the right place As an interviewer. Ask the project sponsor for names of the people you should initially interview.techniques to use before and after an interview Tom Mochal recently provided excellent tips on interviewing techniques to gather project requirements. Prepare yourself The business problem you are trying to understand has a domain. A broad understanding of a business problem depends on interviewing the people who know something about it. If interruptions are a risk. convenience or decorum may dictate a meeting in the interviewee’s office. Recognizing the overhead of preparation and follow-up.
It may help you organize and clarify questions. particularly if you are new to the subject area. your notes contain much of what the interview provided in value. apologize for the interruption and ask if he or she has a few minutes to answer your follow-up questions.such books are often very valuable. 23 . you may discover a perspective on the interview you hadn’t considered. Ask for a second opinion When preparing for an interview. Be sure to ask permission from the interviewee before you begin recording. If you did not tape the interview. Mentors are probably your most valuable resource for learning to speak the lingo. Follow-up the interview Review and clarify your notes Good note taking is an important interview skill -. Next steps While preparing adequately for a requirements interview does not guarantee success. what often ensues is time. In addition. When you call. or the project is complex. By having someone else review your questions. perspectives. Adequate interview follow-up improves the quality of the requirements you uncover. Be honest and indicate why you need to record the interview. What am I expecting this person to know? Think about the interviewee’s role. What is the context of the interviewee relative to the business need or opportunity you are investigating? Existing operational documentation may provide guidance. sure to thank them for their time and interest in the project. ask for a better time to call. or organizational statuses are sometimes barriers to conducting a follow-up interview. Consider asking a peer to review the questions you plan to ask. write down the questions you intend to ask. While you can ask the questions by e-mail. Most people appreciate getting a follow-up phone call to clarify a few points.and the Web is increasingly a good source. the answers to your questions may have only uncovered a portion of the requirement you hope to define. Otherwise. the interviewee may have intended something other than what was said. Ask follow-up questions It is common to have follow-up questions for the interviewee. but you have to prepare “what” questions to ask. but there are plenty of bad questions. review your notes as soon as possible after the interview. Plainly indicate the tape will not be shared with others. Travel distance. Send the interviewee an e-mail with the requirements as an attachment.whether you recorded the conversation or not. A second pair of eyes may also help you root out improper questions. difficult schedules. Thirty years of interviewing people has taught me that there are rarely bad answers in an interview. come prepared to ask good questions. Either way.consuming and unsatisfactory. and interests in the context of the project. If you did record the interview. A peer’s suggestions may add great value to questions you plan to ask. Consider asking a business expert to recommend a book -. If they are busy. Summarize each of the requirements you heard. Be Consider recording the interview If you have only one opportunity to interview someone. Start by asking yourself: What is the project scope? Rely on a project charter to provide the context for the questions you should ask. Invite them to review what you wrote and ask them to contact you to correct the requirements. knowledge. your notes probably summarize key points or identify subject areas to explore further. failing to prepare puts your interview at risk. you may miss important themes or lose clarity on a topic. “How do I know I understood the stated requirements?” Even if you recorded the conversation and listened to the tape. bring along a tape recorder. Tom’s article describes “how” to interview. Prepare good questions Although you may not use all of them. Summarize your notes and ask for feedback Ask yourself.
instead of the work being abandoned or thrown away. there may be some aspects that can be reused. It’s also possible that the prototype can be used as the basis for developing the final solution. the first prototype should still be put together quickly. There was no thought that somehow this PowerPoint prototype would be reused further as the project progresses. The useful life of a prototype will vary according to the project lifecycle model. you’ll throw it away after the requirements have been gathered.Use prototyping to visualize project requirements A prototype represents the shell of an actual production application. start of the final solution. more business logic is also placed into the application. or that some components can be reused later in the project. Typically. a prototype is not used to validate whether a proposed solution works. I’ve seen online applications that appeared to be running on the web. Remember that the prototype does not have to be the 24 . when. As you receive requirements. and are especially useful in visualizing the look and feel of an application and the process workflow.) The main purpose of a prototype is to gather and document requirements. The prototype starts off as a shell that contains the online screens. If you’re using an iterative development approach. if you build a prototype. the team members built the prototype in PowerPoint or Excel. not the complex business logic that goes behind it. In the second pass. At this point. What happens to the prototype? There are two options for what happens to the prototype once it’s built. In this case. in many instances you’ll build a prototype using the same technology as the final solution. There should be very little programming of the core business processes and only enough program code to allow the prototype to go from screen to screen. You may be able to leverage some of the physical components of the prototype as a starting point for the Design and Construct Phases of the project. the prototype is updated with the new requirements. Prototypes are built early in the development lifecycle. In summary. However. and they’re used to provide valuable insight into the look. (Sometimes people call the first production implementation a prototype. the first one is more aptly called a pilot test. Instead. The main purpose is to gather requirements. This is more aptly called a proof-of-concept. the prototype shell is used as the basis for developing the final solution. it’s no longer called a prototype. in reality. It’s possible that the prototype can be thrown away. prototypes are used to gather requirements. Complete or partial throw-away. Iteratively develop into final application. The point of the prototype is to provide a visual representation of the application. and general workflow of an application. If you’re pretty confident that you have a good set of requirements. but that’s not correct. you should document them in the same way you would document the additional requirements you’re gathering though other means. You then use the prototype to gather additional requirements. Likewise. After you build an initial prototype you should show it to the clients to validate the work done so far looks okay. On the other hand. If you have multiple implementations. feel. there’s not necessarily a reason to build an initial prototype.
If not. Create a detailed workplan. signifying that they agree on what is planned. cost. you might think that companies would be happy to just have their project finish with some degree of success. For example. Past the planning horizon. Despite the odds. the workplan can be created. in planning an Exchange migration. cheaper. when the workplan is completed. reflecting the increased level of uncertainty. The planning horizon will 25 . Identifying the project manager is easy. That’s not the case. and better. with an emphasis on jumping right in and beginning the work. if necessary. if one exists.10 best practices for successful project management Given the high rate of project failures. The only way that these objectives can be met is through the use of effective project management processes and techniques. The workplan provides the step-by-step instructions for constructing project deliverables and managing the project. build one the old-fashioned way by utilizing a workbreakdown structure and network diagram. the project definition should include the following: Project overview: Why is the Exchange migration taking place? What are the business drivers? What are the business benefits? Objectives: What will be accomplished by the migration? What do you hope to achieve? Scope: What features of Exchange will be implemented? Which departments will be converted? What is specifically out of scope? Project Workplan 2: Create a planning horizon After the project definition has been prepared. Assumptions and risks: What events are you taking for granted (assumptions). This list outlines the major phases of managing a project and discusses key steps for each one. Initial effort. Once approved by the customer and relevant stakeholders. You should use a prior workplan from a similar project as a model. The time spent properly planning the project will result in reduced cost and duration and increased quality over the life of the project. but who is the sponsor? It might be the CIO for a project like this. it becomes the basis for the work to be performed. This is your planning horizon. The project definition is the primary deliverable from the planning process and describes all aspects of the project at a high level. including assigning resources and estimating the work as far out as you feel comfortable. This is a mistake. Planning 1: Plan the work by utilizing a project definition document There is a tendency for IT infrastructure projects to shortchange the planning process. Who is on the project team? Are any of the stakeholders represented? Signature page: Ask the sponsor and key stakeholders to approve this document. and duration estimates: These should start as best-guess estimates and then be revised. lay out the project at a higher level. organizations expect projects to be completed faster. and what events are you concerned about? Will the right hardware and infrastructure be in place? Do you have enough storage and network capacity? Approach: How will the migration project unfold and proceed? Organization: Show the significant roles on the project.
users start to complain that their converted e-mail folders are not working correctly. especially early in the project. the frequency might be every two weeks. 5: Look for warning signs Look for signs that the project may be in trouble. communication. For instance. especially early in the project. A big project. If the tendencies are not corrected quickly. You discover that activities you think have already been completed are still being worked on. testing activities. After the 26 . If your project is small. workplan has been updated. such as 4: Manage the workplan and monitor the schedule and budget Once the project has been planned sufficiently. If not. This will include sections on how the team will manage issues. no project ever proceeds entirely as it was estimated and planned. and duration. the impact will be unrecoverable. Project Management Procedures 3: Define project management procedures up front The project management procedures outline the resources that will be used to manage the project. In theory. since you already have agreement on your project definition and since your workplan and project management procedures are in place. scope change. For example. but this is a warning. If common procedures have already been established for your organization. the only challenge is to execute your plans and processes correctly. Team morale starts to decline. execution of the work can begin. Review the workplan on a regular basis to determine how you are progressing in terms of schedule and budget. There is a tendency to think you can make it up. Look at the amount of money your project has actually consumed and determine whether your actual spending is more than originally estimated based on the work that has been completed. Deliverable quality or service quality starts to deteriorate. Of course. and so on. High-level activities that were initially vague need to be defined in more detail as their timeframe gets closer. It is important to be able to manage the project rigorously and proactively and to ensure that the project team and all stakeholders have a common understanding of how the project will be managed. determine whether the project will be completed within the original effort. Identify activities that have been completed during the previous time period and update the workplan to show they are finished. this may need to be weekly. Determine whether there are any other activities that should be completed but have not been. The challenge is having the rigor and discipline needed to apply your project management skills correctly and proactively. be proactive. Quality-control steps. risk. Either work with the team to determine how the remaining work will be completed to hit your original budget or else raise a risk that you may exceed your allocated budget. You need to rely on unscheduled overtime to hit the deadlines. users whom you think have been migrated to a new platform are still not. Monitor the budget. quality. These could include the following: A small variance in schedule or budget starts to get bigger. If so. determine the critical path and look for ways to accelerate these activities to get you back on track. For larger projects. and project management time starts to be cut back from the original schedule.move forward as the project progresses. cost. utilize them on your project.
and the project manager needs to be diligent in guarding against it. there are still two major areas of scope-change management that must be understood to be successful: understanding who the customer is and scope creep. Many projects fail because of scope creep. Those events identified as high-risk should have specific plans put into place to mitigate them so they do not. or people who are impacted by the project. but you are “assuming” that the positive outcome is much more probable. For each risk. in fact. they should also determine the probability that the risk event will occur and the potential impact on the project. sometimes the project manager doesn’t recognize the small scope changes that get added over time. Don’t cut back on the activities that ensure the work is done correctly. the sponsor might be the CIO or CFO. 7: Guard against scope creep Most project managers know to invoke scope-change management procedures if they are asked to add a major new function or a major new deliverable to their project. One manager might want chat services for his or her area. since they are the only ones who can add funding to cover the changes and know if the project impact is acceptable. they can’t make scope-change decisions. raise visibility through risk management. (Low-level risks may be identified as assumptions. and put together a plan to proactively ensure that the project stays on track. and they can’t give your team the approval to make the change. the sponsor (or a designate) must give the approval.) Some risks are inherent in a complex project that affects every person in the company. Scope creep is a term used to define a series of small scope changes that are made to the project without scope-change management procedures being used. In general. Managing Scope 6: Ensure that the sponsor approves scope-change requests After the basics of managing the schedule. 9: Continue to assess potential risks throughout the project Once the project begins. a series of small changes — none of which appear to affect the project individually — can accumulate and have a significant overall impact on the project. Another might want an exception to the size limits you have placed on mailboxes. periodically perform an updated risk assessment to determine whether other risks have surfaced that need to be managed. However. 27 . the project sponsor is the person funding the project. That is. Requests for scope changes will most often come from stakeholders — many of whom may be managers in their own right. Other risks may include not having the right level of expertise. and problems integrating smoothly with existing products or equipment.an Exchange migration. Even if you have good scope-management procedures in place. managing scope is the most important activity required to control a project. Although there is usually just one sponsor. a big project can have many stakeholders. unfamiliarity with the technology. there is potential risk involved. Managing Risk 8: Identify risks up front When the planning work is occurring. In proper scopechange management. Medium risks should be evaluated to see whether they need to be proactively managed. If you cannot successfully manage through the problems. If these situations occur. It doesn’t matter how important a change is to a stakeholder. occur. For infrastructure projects like an Exchange migration. With scope creep. raise an issue. the project team should identify all known risks. Many project failures are not caused by problems with estimating or team skill sets but by the project team working on major and minor deliverables that were not part of the original project definition or business requirements. can affect everyone in your organization.
or it may be an action item that needs to be resolved at some later point. 28 . it may not really be an issue. by their nature. The project manager should manage open issues diligently to ensure that they are being resolved. Real issues. Or perhaps the Windows forest isn’t set up correctly and needs to be redesigned. the Exchange servers you ordered aren’t ready and configured on time. It may be a potential problem (risk). If there is no urgency to resolve the issue or if the issue has been active for some time. must be resolved with a sense of urgency. For instance. in an Exchange migration.10: Resolve issues as quickly as possible Issues are big problems.
90 percent.JAD sessions will speed up the project definition process Question The last time I managed a project. it seemed like it took forever to get all of the major stakeholders to agree on what we were doing. This includes gathering business requirements. building a quality management plan. First. in fact. that you have already become familiar with the “quite a long time” process. this is not about reducing turnaround time by 10 percent. Notice that I did not say it would dramatically reduce the cost. So. Many of them read the document and say fine. In particular. The normal way Let’s briefly recap how you normally define a project. your management and sponsor are willing to pay more for a process that takes much less time. Depending on how the JAD is implemented. Answer You’re right. The technique is called joint application development. There is a specific technique (or set of techniques) for more rapidly gaining a consensus from a group of individuals. I have subsequently read about a JAD technique that might help us get through this process faster. the JAD technique can be applied to a wide variety of areas where consensus is needed. Judging by its name. but that’s not the case. 80 percent. and so on. or they may disagree with some of the content. or perhaps even two days. The dramatic reduction in time comes from removing the time required to move information from person to person. They give you enough information so that you can start to talk to other interested stakeholders. creating a project work plan. cost more than the traditional methods. stakeholders. Enter the JAD session The purpose of the JAD session is to dramatically reduce the timeframe required to complete a deliverable where consensus is required. you might think that this technique only applies to developing software. However. from your question. JAD sessions can result in dramatic improvements—maybe 75 percent. Depending on how controversial the project is. in many cases. It appears. he or she can ask it 29 . If a stakeholder has a question about scope. You begin to write a project definition and realize you don’t have all the information you need. based on your question. you may get a consensus on the project definition quickly. the technique can be applied to help define a project. or it may take quite a long time. or JAD. but some will have questions. However. the time required to produce the project definition might be reduced from six weeks to one week. How dramatic could the time savings be? Very dramatic. What can you tell me about it. it may. you might talk to your manager and the project sponsor. You create a draft project definition that is circulated back to these The JAD process The key concept of a JAD session is that you get all of the major decision makers. or higher. and perhaps another round of discussions takes place to provide further clarification and to build a consensus. so you make a second round of talking to people to ask clarifying questions. The disagreements must be taken back to the sponsor for resolution. The process of gaining approval obviously had value since there were some major differences of opinion on what the project was to accomplish. As an example. Although I don’t know the origin of the term. and knowledge providers into one place all at the same time. the time required to get everyone’s acceptance was unacceptable. and is it something that can be used on a project? stakeholders.
It’s fine to invite the project sponsor and the major clients and project team members. and noting any action items. This is important: The objective of the JAD session is to go through all of the items that need to be discussed and reach a consensus on what needs to be done. A JAD session might be just what you need if it would take you a long time to reach consensus on your project definition under normal circumstances. instead of the 30 or more days under a traditional approach. we used the session to gain a consensus on the current state of project management in the organization. The sponsor must work with you to identify the right people and make sure that they will all make the time commitment necessary (including the sponsor). The JAD session The concept of the JAD session implies more than just getting everyone together for a day to discuss all the issues. 30 . documenting decisions. as well as information providers. It was probably more expensive to use the JAD approach. Case study I used JAD techniques on a project to implement project management processes at a Fortune 500 company. it would normally have taken us at least a month to get with all the key players around the world. and gain agreement on a document that described the current environment. These people came from around the world. A two-week process of getting a question clarified and answered can instead take place in 10 minutes.in the context of the JAD session. But what questions might arise that require others to be there as well? All decision makers must be present. Instead. or even during the session. it’s not going to be successful. that is the commitment that needs to be made. gather their feedback. Since this was a worldwide project. These include: Identifying the right people and making sure they are there. The people required to answer the question are in the room and can answer the question immediately—there is no time delay and no misrepresenting the question. and that the meeting is as productive as possible. and have everyone approve the final document very soon after the JAD session is over. Spending the time necessary to reach conclusion and consensus. Using a facilitator(s). In our case. There needs to be someone taking notes. Get yourself a facilitator and a scribe and get everyone together to hammer out and agree on the details of your project. Normally. we identified the right group of people and brought them all to our headquarters for a three-day JAD session. The information providers can be oncall if needed so that they do not have to attend the entire session. but the final deliverable was completed and approved in three days. There is usually a set of formal techniques that are applied to these sessions to make them as productive as possible. You should be able to complete the project definition immediately after the session. if possible). The facilitator makes sure the discussion stays on track. We also felt like it was of higher quality. If you hold a JAD session and none of the participants can make decisions or the people with information are not available. because all of the right people are there at the same time. If this requires everyone to get together for a week. then all of the participants must make a full-day commitment. Having someone take notes. If there are cofacilitators at the meeting. the second person can be the scribe. a formal JAD session has a formal facilitator (a trained facilitator. If this requires a one-day session. that meeting rules are followed. since the contributors were all talking face-to-face.
on the surface.” This is not specific enough to be a requirement. he’s offering an opinion — not a requirement. the client will provide an opinion on the features and functions of a deliverable. “I think we should allow our vendors access to this information. Opinions: While opinion statements can be requirements. In fact. a client manager may tell you. if a client manager tells you that he thinks the company is spending too much money on the project. False requirements come in many forms. a user might tell you. you’ll often hear information from clients that. These details explain the features and functions of the products or deliverables the project needs to have. However.” This isn’t a requirement since the typical user doesn’t have the power to make this type of decision. For example. and these are valid statements. Project-related statements: Requirements describe deliverables — not the project. If you could ask your clients about requirements and know they were responding with exactly everything they needed. You need to ask some follow-up questions to learn exactly how the client wants the application to help employees. “I want this application to make employees’ lives easier. In many cases. If a client states that she wants the project completed by a certain date. if a client tells you that “we should prototype this solution first. For instance. it just usually isn’t that easy. Make sure to ask follow-up questions to determine the real requirements behind the statement. For instance. appear. Comments from the wrong person: It’s important to know the role of a person providing requirements. For example. Learning how to quickly recognize these false requirements and how to dig deeper for the details is vital for a project manager. your sponsor might tell you. gathering requirements would be a piece of cake. in the course of the requirements-gathering process. Unrealistic or not testable: You might hear requirements that are really just marketing hype or extreme hyperbole. or perform.” This isn’t a real requirement since you can’t test or validate it. We call these items false requirements. “This product needs to be able to run on the moon. requirements describe how a product or service should act. Here are some of the more prevalent categories: Vague requirements: How many times does a client offer a statement that contains a hint of one or more requirements but doesn’t offer any kind of specifics? Vague requirements require good follow-up and probing questions to make sure you have the correct level of detail. many times they’re not.” he’s giving you input for the project approach — not a requirement. It can help save time in reworking the project as well as prevent further confusion later in the project4 31 . she’s giving you a schedule constraint — not a requirement. so you can determine if the information he’s providing is consistent with his authority.Don’t fall prey to these false project requirements In project management. appear to be requirements when they actually aren’t requirements at all. However.
Next. Like any process. past performance can be an indicator of the future. two days may be right on the mark. You might be surprised by the patterns that develop. And if you’re a project manager. “Is five days enough time?” “Can you do it in 32 . and you get a reasonable task-by-task break down of the two days’ work. you will surely come to rely on estimates of others. Left hidden. you know your developers are always missing their estimates. project estimates are only as good as the individual estimates associated with the component tasks. perhaps they should be thinking about their estimate some more before you start relying on their figures. 2: Ask for details (proof) Learn the justification for an estimate. tasks. 5: Bracket the work This is for those who just can’t come up with a time estimate for the work. Metrics also go a long way toward improving estimates. Ask questions. at least you will know that they gave it some thought. But if your developers just shrug their shoulders. there isn’t a great deal of information on getting better estimates from others. Don’t be surprised if the estimate actually goes up. because there was probably four days’ worth ofwork to begin with. those tasks would have surely destroyed the timeline when they came to the surface and jumped onto the critical path. just start capturing expected date versus actual delivery date. As much discussion as there is on the estimation process. Vetting the estimates you get today 1: Let history be your guide It is true: History does repeat itself. Unless you’re in one of a small handful of roles. why would anyone think the estimate will hit this time? Beats me.10 ways to avoid stupid project estimates Projects run on estimates. How long does it usually take? You don’t know unless you track this information. but challenge the developer or development team to explain why they think it will take so long. It would not be the first time I’ve seen a discussion with developers expose previously undiscovered project tasks. Overall. it may be time to worry. If you ask why they think it will take two days. 4: Measure Okay. but by how much? If you aren’t measuring it. a deep dive into this topic would be an entire article (or two) in itself.and help you avoid leading your project astray before it ever starts. This also provides a great opportunity to assess their assumptions. I can’t tell you the number of times I’ve seen developers give an estimate oftwo days and actually take four. This also ties into the history suggestion above. 3: Challenge the numbers Push back. If they can’t. While not great news. Project managers seem to do this pretty naturally. but some people continue to fall for it. more manageable. There’s nothing wrong with that. even if it’s just to frame your own estimates. If it has taken twice as long as the estimate the last five times an estimate was given. you really don’t know whether you have a big problem -. you can’t improve it if you don’t measure it. But if you don’t have a clue where to start. try helping them break down their work into smaller. Here are a few ideas to help you see this aspect of estimating more clearly -. If they can justify their estimate. the estimates of others are probably all you have to work with. First. Unfortunately. Unlike the stock market. The problem is that I also see people in meetings repeatedly believing them.or maybe don’t have a problem at all. You either have to provide estimates of things such as how much effort your task will require or you will need such information from others. it’s still better to find out about this sooner rather than later. you may find it useful to use a simple bracketing technique to help the person zero in on the figure that is appropriate.
If you have reason to suspect an estimate may be off. it will take. When was the last time “all went well”? There’s nothing wrong with qualifying an estimate. That is certainly good to know. If you create the situation where it is better to beat an estimate than simply meet it. you may have some more digging to do. once those people have proven themselves. for example. 9: Reward and penalize Penalize the bad estimate. Celebrate when estimates are hit.. Provide feedback to the team members. and then go with the one in the middle. but don’t let the value stop there. and he wrinkles his nose at it. you should be challenging and asking for details throughout this process. Of course.” comes from. it must also be one in which everyone strives to improve the quality of their estimates and the notion of providing a bad estimate is as bad as providing bad program code. 7: Remember that two heads are better than one Run your figures past someone who might have experience with your type of project. you don’t need to tar and feather the offenders. Improving future estimates 8: Give feedback You have captured task estimates. From this. Seek an informal read from other members of the team. 10: Develop a culture Using the correct rewards and penalties goes a long way toward establishing the right culture. or an estimate flawed by an innocent miscommunication. When estimates are missed. That is where the “If all goes well. it’s one in which those providing estimates feel safe in providing accurate information as opposed to providing the information they believe supervisors want to hear. There might be something to that approach. but adding an unrealistic assumption as a way to give a bad estimate only hurts the project. you’re probably getting your estimates from the team’s point person -. they say you should get several estimates. it may add some risk to the accuracy of any estimate you receive. your job will become considerably easier. or if the team has a bad track record for this sort of thing. Generally speaking. it’s generally because that shorter number is what’s expected. When estimates are shortened. Perhaps you’re a sucker for good news. if you can get peer pressure to “manage” the estimates. so provide them the tools and a few suggestions. If everyone is of a like mind. people really do want to do a good job. You want to drive toward behaviors that give better estimates.. An objective third party is exactly what you need to free you of your bias and give you a clearer view of reality. Be careful about rewarding beating an estimate differently from hitting it. When working with a team. but you can treat it as a remedial education opportunity (the very act of which will be a penalty of sorts). Your folks will be able to take it from there. all the better. Ultimately. While this is efficient. If you run the team estimate past an individual developer. a blatant falsehood to avoid having to face some development reality. you probably have as good a number as you can expect. you may have learned that certain 33 . Perhaps they are telling you what you want to hear. groups always underestimate by 25 percent. You may be getting the result of a faulty team consensus. Help them identify patterns in how they estimate and challenge them to find the root cause of their bad estimates. throw out the highest and the lowest.less than 10?” Continue in this fashion until you get a figure that everyone is comfortable with. you will create an incentive for overestimating. However. not that a task estimate is too long. but what is the right culture? Certainly.a lead developer. 6: Get a second opinion When you’re hiring a builder. Managers must also respect those providing them with information. Be serious. and you have tracked actual. If this person is not on your project. especially if there is a wide variance in the estimates of the individual team members. a second opinion may be in order.
you don’t need to do everything yourself (nor could you) to get estimates you can trust... Exercising the simple ideas above will help you filter out the bad numbers you get today. Fortunately. and generally make your life a whole lot better -. improve the numbers you get tomorrow. one estimate at a time You can’t run a project well with bad estimates.at least as far as your project is concerned. any more than you can build a house with faulty bricks or lumber.Improve your project. 34 .
Yet the success of implementing a software-based project collaboration system depends wholly on the willingness of potential users to integrate the system into their work flow and work habits. Choose software with a friendly. and learn conventional software. bookmarking. project managers. and people will be more willing to give it a try. Wikis. live. photo tagging. They have become bogged down in paper-based systems or standalone software and have not yet realized the benefits of turning to a networked environment for their crucial work projects. Rather. To help avoid such resistance. more than a third of small and large businesses will adopt SaaS into their technology portfolio during the next year to help bolster such activities as project management and internal collaboration. Stang. and business development managers should provide input into the PPM [project and portfolio management] investment decision. it should be brilliant in its simplicity. and instant chat. such as e-mail integration. and play. 1: Start with the basics— incorporate everyday tools Choose software with familiar. About 80 percent of those considering it say they plan to adopt it within the next 12 months. as teams can grow virally and expand as more employees are pulled in. install. 4: Collaboration promotes adoption Tools that offer enhanced collaboration abilities lead to more rapid adoption. businesses should consider 10 practical steps that can enable the company to gain the support of its staff and the efficiencies inherent in project collaboration software. Gartner research 3: Loosen up—go subscription-based Subscription-based pricing is more flexible. 5: The key word is “user” interface Remember that it’s a user interface. software as a service (SaaS) has made this phenomenon possible. and blogs—collaboration has become the dominant characteristic in the way we work. According to a report by THINKstrategies and the Cutter Consortium.” —Daniel B. distribute. so you’re not locked into expensive commitments. the tool might not be capable of providing all promised benefits. Pay-as-you go flexibility allows organizations to add or subtract functionality as needed. everyday tools. This means selecting software—most likely SaaS—that doesn’t require an IT 35 .10 ways to overcome resistance to project collaboration software Since the emergence of Web (insert arbitrary number here). not a developer interface—navigating the system shouldn’t be like solving a Rubik’s cube or completing a scavenger hunt. To a large extent. online applications. so you can deploy on a small scale first to make sure it is right for your company. 2: Novel concept alert: Ask the user first Consult the people who will actually be using the software before making a purchase. the quicker employees can familiarize themselves with it. some project managers who may otherwise eagerly share vacation photos with family members through Flickr or freely respond to a blog posting remain reluctant to adopt project collaboration software. Take it from the experts: “IT professionals. This makes introducing new software less intimidating right from the start. otherwise.0—with social networks. intuitive interface designed with the end user in mind. Unfortunately. 6: Fast deployment = fast adoption Common sense tells us the quicker a solution is deployed and is up and running. eliminating the need to buy.
bribe employees with cash and/or fabulous prizes. they will be motivated to follow suit. 8: Less is more Make sure to distinguish between “must have” and “nice to have.” Inundating your team with a solution that has all the bells and whistles will intimidate and veer users away from a smooth adoption.” said Jeff Clavier. Apply the 80%-20% rule. 36 . It works! 9: It takes a village community Offer a help community—quick. anonymous online assistance forums for troubleshooting and shared experiences. 7: Adoption flows downhill Lead by example.SWAT team of installers or hours-long training sessions. 10: Offer cash rewards When all else fails. Venture capitalists are noticing this trend: “What we see now is a huge increase and adoption of Web apps that are equivalents of business or consumer apps that you used to install on your PC or Macintosh. managing partner of SoftTech VC. If others see team leaders using the software.
” and “how. each detail-level use case narrative is a story that answers the “who. They define “who” and “what” pretty well.” and “how” of a business process. It will simplify communication during the meeting if you number each high-level requirement in the electronic document before sending it to the team. each one with a requirement on it. Ask each person to come to the next meeting prepared to improve on the requirements. You’ll need enough flip chart pages to hold the high-level requirement notes comfortably — figure roughly eight notes per flip chart. and our world. You should end up with a set of readable 8-1/2 by roughly 3 inch strips of paper. along with the sequence of events. hang flip chart pages side by side on a wall. Bring along some half-sheets of letter-size paper on which to write new high-level requirements. Future articles in this series will describe how to evolve these titles into clear. Unfortunately. If you followed that process. To complete your preparations. and several narrow-tip marking pens.Categorize high-level requirements into use case titles for better project management Many business analysts use Unified Modeling Language use case diagrams to identify the actors and their highlevel actions in a system. Send along an agenda for that meeting containing two work tasks: “Clarify Requirements” and “Organize Requirements. these narratives speak volumes about a system and its functional requirements. Think about the last movie you saw. In this article. Whether you have 50 or 500 high-level requirements. you also understood a participant’s motivations. you can now help the team organize them into manageable chunks. Through the story. Just before the meeting begins. It may not be a surprise to hear that story writing is a very powerful tool for the business analyst. In a broad sense.” “when. also bring to the meeting the usual materials: a flip chart pad. Written in a language both functional staff and technical staff can understand.” “where.” “where.” “why. perspectives. but don’t tell us “when.” Learn how to transform high-level requirements into a set of story titles that can be applied toward functional requirements. You probably remember when a critical event occurred. requirements. each other. let’s assume you now have a rough set of high-level requirements in an electronic document. If the story was told well. masking tape. “”what. or a book you read. Let’s call these slips of paper the “requirement notes.” It is a good idea to make a second set of these notes as a duplicate. copy the requirements text into a new document and arrange three or four requirements on each printed page. Importance of stories Recognizing the importance of UML to a business analyst. UML use cases fail to tell us much about the details of a system. there is a good chance you can retell it. and comprehensive narratives about a business process. and who was involved. you have a good foundation for defining the system’s functional requirements. stories help us make sense of ourselves.” Before the meeting. and behaviors. succinct. Collectively. Print the document and cut up the pages so each requirement appears on its own piece of paper. Before meeting with the team. These diagrams help an analysis team clarify and understand the project domain and highlevel functions. we learn how to transform high-level requirements into a set of story titles. you may wonder why stories are also important. give members an opportunity to review the high-level requirements and fill some holes. Increase the font size to allow easy reading from about four feet.” “why. As a product of your work with the team. Starting from a foundation We began the process of writing use case narratives by helping the analysis team define high-level system 37 .
write a use case title that describes a group of requirement notes from a flip chart page.” “driver picks up carpool rider. you will notice that some of the requirements seem like process-oriented steps. Tell them that there is a duplicate set of the requirement notes available if someone finds a requirement that belongs on two pages. Briefly explain the purpose of the flip chart pages on the wall and talk about the set of requirement notes. have them take a short break and ask that they return in five minutes. Assign one or two volunteers to a single flip chart page. Be silent as they work. Explain that you would like them to arrange the requirement notes on the wall. Ask them to use the half-sheets of blank paper to record any new requirements theydiscover.” Based upon your own review during the team’s break. In the adjacent righthand column. When the whole team seems ready. This meeting will probably require about two hours.” and “driver drives to work. read the flip chart pages. you can probably suggest meaningful titles to the group. Team members are likely to hear a well organized feature set for the system categorized by sub-system. spend a few minutes describing how you will use their work. Give people time to organize their thoughts. (Since tracing the origin of a requirement is important. The team’s first activity shouldn’t take more than 10 minutes or so. As a final exercise. Again. Have plenty of strips of masking tape ready for affixing the notes to the flip chart pages you hung earlier. When team members return and are ready to begin. have each subteam summarize its flip chart page to the whole group. be patient. have the team spend a few minutes examining the whole set of flip chart pages and adjust or add notes as they see fit. A title is a simple declarative statement in the form “actor-verb-object. Begin work on this first agenda item by spreading the requirement notes out on a large table. ask them to reevaluate the requirement notes posted on the flip chart pages. You can measure the completeness of their work by checking for inactivity among the group. Encourage members to take a marker and amend the requirement notes. if the requirement notes described the features of a new accounting system. An ancient proverb comes to mind — “A word is worth one gold coin. At the end. When the work seems done.” Leave the group standing for a minute and let them survey the set of requirements one more time. Ask them to group the requirement notes that seem to fit with one another onto the same flip chart page. Organize the requirements Now you may introduce the second agenda item to the group. I would include “driver starts the car. Indicate you will group the requirement notes and develop use case titles for them.” As you develop this document. copy and paste the electronic requirement notes that fit under the title’s umbrella. 38 . Explain that a use case title describes an actor in the system doing something. Encourage them to talk as they work. we might have use case titles such as “Clerk sets up a new account” and “Supervisor overrides an accounts payable exception. Ask each sub-team to evaluate its assigned page. Do the requirement notes seem well organized? Do all of the notes Next steps The deliverable for this meeting is something I’ll call a use case catalog.) For example. In the left-hand column. carry along the number assigned to the requirement as well. seem appropriate for the page? Should a new requirement be added to the page? Give the sub-teams about 10 minutes to complete their work.Clarify the requirements Start the meeting by introducing the team to what they will be doing. silence is worth two. Create an electronic document that contains a table with two columns. and to rearrange the notes as they see fit.” If I were describing my commute to work as use case titles. Give team members time to stand up and review their previous work. While they are away.
or they may add another half-dozen requirements they hadn’t considered. and advise them to make good decisions along the way.” Lesson learned Following a core principle makes this whole process successful. they own the requirements. Despite imperfections. If you can’t find a home for a requirement. Remember that while you own the process that the team is using. 39 .Others seem like business rules or constraints. Place it in a row in which the use case title is simply “Unknown. While a home may be found for the orphan requirement. Let the tension inherent in early. fuzzy requirements drive them to create clarity. or because of them. You must show them the path to producing good requirements. Some requirements may not fit at all. be honest about it. send the newly drafted use case catalog to the team. They may decide it is not really a requirement. encourage them to explore what they require of the system. the team is best suited to find it.
lack of coherent planning. The first step to creating a “useful” project plan is to figure out what. trying to understand what the frak I was saying. I found the same things I always find in project plans . Not unlike what I find in organizations all over the country. Never one to turn away a job. We use them to record information. post them. was that he had a lot of company in his situation. In the third I put in how frequently they will interact with it. ect. a document. in a lifetime far far away. we need the project plan to convey in order for it to be useful. The good news. while another may put all the weight onto the project manager’s shoulders. Some of this is contextual. The better news was that it’s not that difficult to get out of the psychological rut which leads project managers to create useless project plans. I agreed to speak with him and review the documents his team produced. we try to dig down and figure out who will interact with the project plan and in what ways. a project plan by convention contains all those things. Leafing though the packet. I prescribed him a simple remedy . In this question. or as records of exercises undertaken to understand a problem to name just a few. he had pretty much figured out my standard “yes but” answer. A project plan written to satisfy auditors must meet very specific criteria which might not have anything to do with actually running a proj- 3: What will the project plan contain? “Ummm…” my client said. In the second column I put in how I expect them to interact with the project plan. to communicate information to one or more audiences. and precursor information?” By this time. I generally create a chart when I try to answer this question. when we get right down to it. Trying to write a project plan to cover all “whats” generally leaves the author with a confused. in a given context.four questions I always ask myself before I sit down to wok on a project plan. When we asked the first question we defined a use and an audience. to brainstorm possibilities.A four-step prescription for writing better project plans A long time ago. 2: Who will use this project plan? My client’s suspicions raised even further when I showed him this one. 1: What do you want this project plan to do? My client’s eye’s crossed when I gave him the first question. the real question is what tasks? How do we filter and vet the vast amounts of process information required to run a project into a useful document based on what we need it for and who will interact with it? Do 40 . and a very limited control of how tasks interact to create workable processes. In one organization the PMO may dictate that developers always create and update their own tasks. “A project plan organizes project work in a reportable fashion” he mumbled. Yes. yes and no. A project plan written to aid executive reporting might not contain the information an auditor wants. In the first column I put roles and/or names if I know them. Documents exist for a variety of reasons. “Don’t project plans contain tasks. useless mess. However. A project plan is. a client asked me to help their PMO produce useful project plans. I assured my client. just as one written to help the project manager actually track multiple interwoven sites will read differently than any of the above. dates. These questions are as follows. no focus on document purpose. “Didn’t we answer that in the first question?” Well. then ignore the hoary artifact in favor of more mutable spreedsheets or calendars.
how do we determine what needs to be in the project plan and what doesn’t? I wish I had a handy trick for making this filter. and compromises which the author might know nothing about. I suppose. But that is another story… 4: Why is the project plan important? “Okay.the author’s and the reader’s. Each author can with a little bit of work uncover his own motivations.we just drop everything into the project plan and hope someone will get around to updating it? Do we use a very minimalistic. I get the first three. critical path kind of approach. we have to know why a reader feels the document might be important to him. Conclusion Using these four questions. For a given reader. this is one of those “technique=time+context+person” things. can we hope to meet his expectations. my gentle readers would justifiably want to flog me. They ran into some other. For a project plan. we have consultants. He may never have to revisit the document again to gain benefits from it. but that’s just the way the world works sometimes. This situation unfortunately dooms the fledgling project manager. It’s vitally important to differentiate between the two. Unfortunately. especially if we see a positive improvement in the author’s productivity or development. the document is only successful if it meets his expectations about what information he will find. Then. But this is…” I thought I would cut to the chase. To use this blog as an example. if I titled this article “How to make a great cake”. because it looked like my client was about to get a headache. political situations later on which they found the questions useful for as well. If we do the later. and only then. We generally call this a success. the act of writing the document is often sufficient to organize his thoughts and allow him to move forward. more complicated. corporate setting can become unwarrentedly challenging due to politics. otherwise we end up with yet another confused mess involving poor communication and broken expectations. Uncovering the why of a document in a 41 . This is why. lack of focus. How we build the filter depends entirely on the answers to the previous two questions along with a host of other process related variables. For an author. Every document can be important in at least two contexts . my client did manage to improve his project managers’ project plans.
During the Project 2 .
you may be allocating team members to a five-day 42 . Once you understand the critical path. you should revalidate dependencies.10 ways to get a slipping project back on track This information is based on the articles “Correct your off-schedule project with these techniques. Check all dependencies to make sure you have all your facts correct before you move into more drastic measures to bring the project back on schedule. your first obligation as the project manager is to try to determine the cause. they can get morework done in the same amount of calendar time. 3: Double-check all dependencies Schedule dependencies represent activities that must be completed in a certain order. many times you’ll find that you’re trending beyond your committed deadline date.For example. but one logical place to start is with overtime. though: Delaying some work may end up changing the critical path. if the project is trending over deadline. For example. Regardless of how it happens. you have many options to solve your problem. Note that this list is not prioritized. since it’s possible that the schedule is being lengthened by invalid dependencies between activities. your choices dwindle. Overtime may be the best option if you’re close to the end of the project and just need a final push to get everything done on schedule. the situation will probably recur. If you discover that happening. If you’re trending over your deadline. Your second task is to try to make corrections that will get the project back on track. 2: Reallocate resources The project manager must first understand what activities are considered most vital to the project’s success. when they can really be done in parallel.” by Tom Mochal. if you’re building a house. Look at this list of techniques and see which ones can be applied to your situation. while others could be applied better in another situation. 4: Check time-constrained activities Time-constrained activities are those with durations that don’t change based on the number of resources applied. or on the “critical path. This option may also have cost implications if you need to have contract resources work overtime. If you’re still early in the project. Invalid dependencies may make it appear that activities must be performed sequentially. by definition it is the critical path that’s late. Always make sure you double-check the critical path each time you change the schedule. but that they know to be invalid. At the beginning of a long project. you cannot start putting up the frame until the foundation is poured and dried. It’s not uncommon for some of the work to be harder than originally anticipated or to have turnover on the project that requires you to bring new people up to speed. This will allow you to get the project back on track by delaying or stretching out some work. you also may be able to issue comp time after the project is completed. If you look for remedies without knowing the cause. Be careful.” and “Apply these techniques to get your project back on schedule. Some of the techniques may work in one instance. Sometimes the scheduling software accidentally adds a dependency. But toward the end. Sometimes you discover that activities were simply underestimated.” After all. It might make sense to have the team members review the schedule to see if they find dependencies that the project manager thinks are valid. see if resources can be moved from other activities to help resolve the issue. Anyone who’s worked on project teams knows that a variety of factors can move a project past its deadline. 1:Work overtime Everyone hates it. If people work more hours. there are probably more effective strategies. Sometimes the project manager adds the dependency but on later review decides it doesn’t really exist. If you’re toward the end of the project.
For instance. the original 10-day estimate).usually leads to some incremental cost increase to the project. you could see whether two people could complete it earlier. One of the goals of crashing the schedule is to minimize the incremental cost. crashing -. you may not be adding any ince- 43 . if one person were assigned to complete an activity in 10 days. Check all of these timeconstrained activities to validate the timeframe. For example. you can simply swap people who are working on different activities within your project.in exchange for completing some work ahead of schedule -. In another example. Another example involves designing an IT application. but crashing also means you try to get the biggest schedule gain for the least amount of incremental costs. if you were fast tracking. Perhaps then the activity would take four days. Perhaps they aren’t as productive in this particular area as they are in other areas. you will have accelerated the schedule at an incremental cost of two workdays (two people for six days vs. Remember that the activities on the critical path are key. You may have options to assign a more productive resource to those activities. The foundation will start to harden there and might allow you to erect the frame on that side. Fast tracking usually involves risk that could lead to increased cost 6: Crash the schedule Crashing the schedule means applying additional resources to the critical path. The class takes five days if one person attends. there may be opportunities to replace resources. One cause you may find is that you have one or more resources that aren’t as productive as you planned. If cost is not as important as the deadline. 7: Fast track it Fast track means that you look at activities that are normally done in sequence and assign them totally or partially in parallel. while reassigning a less productive resource to noncritical path activities. the more the incremental cost will be and the less incremental timesavings you will receive. In some instances. the more resources you throw on an activity. you could further crash the schedule by applying three resources. mental cost to the project. Regardless. since you’re applying twice the resources for half the time. Normally. However. perhaps the time could be reduced to one day by paying more for overnight delivery. Perhaps you’re making assumptions that could be changed with a different approach. you may still be okay in terms of meeting your overall project deadline. If two resources can complete the activity in five days. In this example. Typically. if the house is large enough. The additional resources may come from within the project team or they may be loaned temporarily from outside the team. or four and a half days. you may have options to fast track by starting to erect the frame on the side of the home where the foundation was poured first. It’s always possible to just throw more resources on the critical path. you would start constructing the solution in areas where you felt the design was pretty solid without waiting for the entire design to be completed. and it takes five days if 10 people attend. However. Other times. you wouldn’t start constructing a solution until the design was completed. while the foundation on the far side of the home is still drying. 5: Swap resources I mentioned that the first thing to do when you’re trending over your schedule is to determine the cause.class. Back to our home-building example. you can’t construct the frame until the foundation is dry. if you allocated three days for a contract to reach a client. you may release a team member and bring in another person. If the activities off the critical path are delayed. Perhaps certain team members don’t have the right skills. if two people can complete the work in six days. However. crashing a set of activities can result in accelerating the schedule. the sequence of activities that must be completed on schedule for the entire project to be completed on schedule.
Usually you can complete less work faster. However. For instance. you may find that some of the internal workprocesses could be improved. Once you know the cause of the problem and your budget flexibility. For instance. All energy should go into accelerating the agreed-to core work. You should look at them first. This could be a result of poor scope change management or it could be that small changes are being worked in under the radar screen. these techniques should be applied next. perhaps you have a daily status meeting that is not providing value and that can be scaled back to once per week. there may be options associated with scaling back the scope of work. and those final changes may result in having to redo some of the work already under way. 9: Improve processes When you look at the cause for the project trending over schedule. this 44 . in our example of designing and constructing an application. discussion still might need to take place as a last resort. if possible. perhaps the timing of completing the reviews can be changed to allow critical project activities to be completed on schedule. at least on a temporary basis. you can determine the best actions to undertake to get you back on track to hit your deadline. one solution is just to deliver the work at a later date. If you think some of the remaining work is not core to the project.and some rework later. as the project manager you must work with the client and team members to ensure that absolutely no unplanned work is being requested or worked on. 10: Scale back the scope of work One option that is usually available is to look at the work remaining and negotiate with the client to remove some of it from the project. For example. In some cases. 8: Prevent all scope change Many projects begin to trend over their deadline because they are doing more work than they originally committed to. Some of these techniques don’t require any incremental budget. it’s possible that the design might change before it is finalized. Determining priorities I’ve pointed out 10 areas to examine if you’re behind schedule. you may find that activities are being delayed because people need towork on their yearly performance reviews. If the remaining work is all core to the solution. try to negotiate changes to the processes going forward. the assumption here is that the scheduled completion date is important to the client. You may also find bottlenecks in getting deliverables approved. Obviously.If the deadline date is extremely important and you can’t move the schedule or the budget. It may be an option to complete this project on time with less than 100 percent functionality and then execute a follow-up project to complete the remaining requirements. even if it’s just one hour. you could discuss eliminating it quickly. While these are important. If you discover delays caused by external processes. Other techniques to accelerate the schedule will result in increased cost to the project. If the deadline date is more important than costs. If you’re at risk of missing your deadline date. Solicit team member feedback and look for ways that are within your team’s internal control to streamline processes. that may be perfectly acceptable.
their projects wither on the vine. If the people who were behind the project suddenly are no longer around. 1: Project sponsors and stakeholders disappear One of the surest signs of the imminent demise of a project is the disappearance of project sponsors and stakeholders. especially 45 . and other resources are sucked in. So when a project is cancelled. On the symptom side. This vanishing act can be a cause or a symptom of the collapse. Management all too often believes that IT projects can be put on hold indefinitely until the budgetary constraints are relaxed. This would not be a problem if the IT industry were like many other industries. Knowing the signs of an impending cancellation can help these workers land on their feet. What is not healthy is when the topic of project cancellation comes up outside of those planned points. from outside the organization. people’s careers are linked to their projects. Be especially wary if the new leadership is 5: Management keeps discussing project cancellation Some projects walk the razor’s edge between cancellation and continuation on a regular basis. especially if it was a sudden and/or involuntary change. and sometimes they are forcibly removed. Be wary when management changes. the phrase “throwing good money after bad” starts getting used in executive meetings when your project is under discussion. watch out. and nothing ever comes out. When you’re over budget or past deadline by more than “just a bit. regardless of how good it is. people. When a manager is removed.” it is a roll of the dice whether the higherups will be willing to put more money and other resources into the project. when the sponsors and stakeholders move on to other things or other companies. workers lose their jobs. and that means that your project’s neck is already on the block. contractors. But the IT industry is filled with temporary employees. After all. one way or the other. When a project is sick. It’s a normal and natural part of the project management process to have a few go/no-go points in the plan or to have milestones that must be met for the project to be allowed to continue. 4: Your project is a “black hole” Some projects seem to be black holes: Money. the more risk there is that your project may be cut. IT pros know that things do not work this way—but good luck explaining that to an executive tasked with a general cost reduction. These projects are typical Dilbert scenarios. all of his or her decisions are open for reevaluation. some people put distance between themselves and the project. and even permanent employees hired specifically for a particular project. consultants. Even long-term investments that are projected to deliver a big payoff can be cut. 3: Money woes abound When a company or organization is financially struggling. where the labor pool is made up almost exclusively of permanent employees. The worse the budget crunch. scope creep. and so on.10 signs that your project is about to be cut It is an unfortunate reality in the IT industry: A large number of projects are cancelled before they are complete. the new head honcho may not see the upside of a project like the previous boss did. that can signal that an “axe man” has just been put in charge. complete with constantly changing requirements. projects that are not showing immediate ROI are in particular danger. 2: Changes in management are rolled out Major changes in management always carry some risk to existing projects. After a certain point. or whether they’ll just throw in the towel. Here are some signs to watch out for. moving targets. On the cause side.
7: Poor leadership casts a shadow on the project Of course. 10: It truly is a bad project Once in a while. they’ll be closing up shop. 9: Your project has low visibility In every company. all of the goals were met. For example. and no one seems to know what they do. but the product fails Every now and then. someone is going to ask why resources are being spent on it. You may be given very 46 . your project may be vulnerable. If you make fun of your project leaders behind their backs. your project was successful by every measure of project success. and so on. Or maybe you keep missing milestones or are way over budget. those employees are the first to go. it is an indicator that your project either is not producing anything useful. your project deserves to be cut. And if no one can explain the purpose of the project. For whatever reason. little time to do something to make the product successful— and if that doesn’t happen. or your project leaders are not doing a good job evangelizing your work. but it’s a fact of life. Your market may have experienced an unforseeable and severe shift in direction right around the time your product rolled out. sometimes your boss’ detractors are right. Regardless. there is a project that is completely successful: The product shipped on time and within budget. For whatever reason. your project is in their sights. and when that happens. When there are enough reasons to discuss project cancellation that it comes up frequently. someone else with a lot more pull is probably sniping at them too. beware. and the milestones and budget were reasonable. they simply lack publicity or even recognition. if there is already an established competitor on the market with a better product than you’re planning or that it sells for less than your product will sell for. even if it’s going well. projects with low visibility are at risk of cancellation. Nevertheless. and your manager really is making a mess of things. or possibly a new competitor came onto the market out of left field with a better product. The ability to foresee the likely cancellation of your project 8: The project is successful. management actually gets it right and cancels a bad project. your project will be at risk. But most of the time. Even good projects are used as weapons in vicious political battles. it will get cancelled unless something major changes. Maybe it’s priced too high. Some projects are like this too. No one likes to think about their project getting cancelled. the company is doing something super-secret and wants to keep chatter to a minimum.when it happens repeatedly. it will become obvious to the “Powers that Be” as well. It’s a shame that executives behave like this sometimes. If it’s obvious to everyone on the project that it is a bad project. Your leader’s opponents argue for the cancellation of the project to diminish the prestige or resources of your boss or to cause embarrassment. regardless of its merits. But it is a reality we all have to face at one time or another. It may simply become clear that the end product will never be successful in the marketplace. The manager who is obviously inept to the staff is eventually going to be exposed. or maybe some bad decisions were made. Black holes (see #4) are not always bad projects. why they are there. When your boss is being stabbed in the back and his or her decisions are constantly being questioned. But the product that resulted is a total failure. Sometimes. And when the layoffs come around. this is on purpose. they may have simply been scoped incorrectly at the beginning. some projects truly deserve to be cancelled. it will be decided that the project is not needed. but too many workers seem to be completely oblivious to the dangers of this situation. or even what their names are. 6: Your project becomes a tool of office politics Does everyone hate your boss? If so. Eventually. And then the product itself completely tanks for one reason or another. some employees come in every day for eight hours. This may seem obvious.
but you may need to balance it with a regular dose of objective consideration so you can decide whether it’s time to move on before someone else yanks the rug out from underneath you.is an important skill for keeping your career healthy. An optimistic attitude about your work is always welcome at the office and is part of being happy. 47 .
Between projects. The International Institute of Business Analysis (IIBA) in their Body of Knowledge defines this understanding as “capturing the necessary view of the business to provide context to requirements and functional design work for a given initiative and/or for long term planning”. Come to each meeting well prepared. we often start conversations with small talk. While stakeholders may have relied on your good leadership in the last project. draft a set of open-ended questions to ask the stakeholder when you meet. The customer may have longstanding and unresolved technical issues that will have to be overcome. Most people welcome a chance to get out of the office and chat. in the Midwest United States. I might ask about his or her children. Where I live. invite a stakeholder to lunch. Middle management may want IT to improve its support process and upper management may worry that recent cost overruns predict the outcome of future projects. Eventually. talk with those technologists who routinely work with the customer. Check with your help desk and familiarize yourself with significant issues the customer has with IT systems.Sustain and broaden customer focus outside of your projects As a project manager or business analyst. You should also understand the motivations and interests of your customer’s clients. ask about concerns the stakeholder may have about operations. If you are new to the industry. Attend conferences and talk with vendors and your customer’s peer organizations. and their organizational vision and goals. Read representative samples of your customer’s process 48 . If there is time in your meeting. Expand your knowledge about the customer’s business You can begin your outside-the-project work by improving your level of understanding about the customer’s business. If you are a business analyst. documentation. you have an important role outside the scope of customer projects. the customer’s operational practices. Are there processes that seem inefficient? How is the customer working to reduce costs and increase profits? Ask about new initiatives they may be considering. they may still harbor ill feelings about your IT department in general. or query about a recent bike or sailing trip. take ownership of it. For example. Make sure you understand it. Capture stakeholders’ perspectives Sustain and broaden your customer focus by building a positive. you should know the industry jargon. which is a good way to help you and your guest to settle into a good conversation. or out for a cup of coffee. I’ll ask about their current systems. There are many ways to gain this knowledge. and promise to follow up with the stakeholder. long-term relationship with stakeholders. If you need clarification on an issue. convince your boss to let you spend time observing your customer’s operations. Are they working properly? Is everyone trained? Is the new system fully adopted? Is support from the help desk working well? Listen carefully for an issue. Your work outside the context of projects helps to identify and resolve issues and concerns. Also. Read industry-specific journals. Your customer’s marketing staff may be a good resource for broad information about their clients’ interests. All of these issues and concerns can be resolved when a project manager steps outside the scope of the project. a working knowledge of your customer’s business is critical to the success of future projects. and build positive relationships between IT and customer stakeholders.
Support the stakeholder I find it helpful to take a view of systems beyond the narrow framework of IT. Try to step outside of your Advocate for stakeholders As a final suggestion. This approach often defuses the stakeholder’s emotions. Many IT-oriented magazines. a government. and the stakeholder begins to see you as valued advisor. emotions for a moment. you can transform yourself from thinking “software solution” into thinking “customer system” — a perspective that includes users. make a recommendation. It wasn’t your fault the customer failed to test adequately before implementing the new system. and learning how a challenging problem was solved. As you build a positive relationship with a stakeholder. How would this observer encourage you respond? (A valuable resource for understanding this approach is Difficult Conversations by Douglas Stone. Listen to the stakeholder and empathize. you may eventually find him or her soliciting your opinion about a new technology your IT department may be adopting. indicate the progress made in resolving any remaining issues and specify when you or someone from your department will follow up with new information. When a crisis eventually arises. you have probably left them with a positive feeling about your interest in them. Would it be more effective to talk with the stakeholder by phone or meet with them in person? Even with this new perspective. et al. After thanking him or her for their time at lunch or coffee. The stakeholder may appreciate knowing about industry peers. Initially. If your response angry as well. journals. you are better prepared to consider how your message will be received.) Set aside your emotions. If so. or service sector). 49 . implement the solution and follow up. physical infrastructure.g. be sure to pass along articles that may be of interest. Since a stakeholder is unlikely to encounter these IT resources on their own. you both have a relationship from which you may reach a mutual understanding and quickly resolve the issue. Also. give them a phone call and indicate you recently read an article that might interest them. follow up with the stakeholder regarding any identified issues. By doing so.. become an advocate. it is natural to feel defensive when a stakeholder calls you to complain about a serious bug in the new production system. Whether they are interested or not. then consider possible solutions. and help the stakeholder understand what you propose. After the meeting. Over time. and organizational culture. If the he or she agrees to the approach. If you remember that technology is just a tool.Try to meet periodically with the same person. it may feel strange to take this step with a stakeholder. Ask if they would like to get the Web link. and on-line media periodically focus on a specific industry (e. such meetings build mutual trust. Always be mindful of the larger goals you hope to achieve. set the e-mail aside and pick it up later. as you write an e-mail response to an angry stakeholder’s question. manufacturing. Remember to manage the issue until it is resolved — even if someone else corrects the problem. Educate stakeholders A fourth straegy involves taking some responsibility for educating your customer’s stakeholders. A phone call works well. and by understanding the stakeholder’s perspectives and interests. For example. How would an objective observer view this conversation? This third person might remind you that IT signed-off on testing as well. You also “bank” goodwill. You benefit by expanding your knowledge of the customer’s business. communicate the issue resolution. or would like to review the pages you tore out of the magazine. business processes. This new perspective has the effect of helping you improve customer support. you reframe your perspective from “IT-centric” into the more valuable “customer-centric” view.
By sustaining and broadening a customer focus outside of projects. you and your IT department become your customer’s most valued technology advisor. As an advocate. Explain how it might improve their operations. facilitate a meeting between the stakeholders and technologist to clarify and resolve the misunderstanding. Valued technology is built on the foundation of valued relationships. while being mindful of their backgrounds and interests.To help stakeholders understand the impact on their business. If necessary. you also have the role of ambassador on behalf of your customer to your own IT department. Create opportunities for them to understand the new technology from the perspective of their business. they will also value having a forum in which voice their interests and concerns. Invite stakeholders to attend the meetings. it is too easy for us to fail in serving our customers. While stakeholders may welcome the learning opportunity. consider developing an exploratory user group. as well as the opportunities and threats associated with using it. or reduce their costs. Next Steps Without strong relationships with stakeholders. Try to represent your customer’s viewpoints when you feel that IT may be ignoring or misinterpreting them. Explain to technologists the customer’s perspective. 50 . increase their profit margin. Help them appreciate the technology’s strengths and weaknesses.
Do what ever you can to recruit the subject matter experts who work well with others. Of course.” Many years ago. Create joint ownership of the project outcome. both sponsors have to support the project and be dedicated to seeing the project succeed. testing. but the customer’s representatives should be business experts as well. and they didn’t. There are four key points to consider: 51 . who are neither shy nor overbearing.Create and sustain a customer focus within projects Whether the clients you serve are inside or outside your organization. Collaborate with customers Whether as a project manager or business analyst. the technologists should know the technology. but never seemed to use the product to pay its own employees! You can’t stay in business that way. train them. Consider the extent to which your technology department is aligned with your customer’s interests. there is room for improvement. and embed them in the development team. Consider adopting several of the customer’s technologists. Start with a project with joint ownership. and knock down hurdles. Be creative. Collaborative projects get a good start by having two sponsors — one from customer management. Sometimes this dictum means. Have some of your development team handle incoming help desk calls for the first few days following implementation. design. and one from IT management. their organization’s food chain to tap resources. What do customers say during post-project reviews about your department? Do your customers have confidence that current projects will be delivered on-time and onbudget? Is communication effective (and respectful) between your department and its customers? If a customer had a chance to restart a recent project. Build a project team that consists of both technologists and customers. It will help if you can ante to match the customer’s financial commitment to a project. and implementation. I knew a software company that provided payroll systems to its customers. 3. you have a unique opportunity to understand your customer needs. Let’s begin with actions you can take within the context of a project. 2. creating and sustaining customer focus is crucial to your success as an IT department. The concept of a joint project team works remarkably well in each project phase — discovery. Take a moment and review a representative sample of the contact points you have with your customers and ask yourself some questions. and provide periodic news releases as the project progresses. “Eat your own doggy chow. would he or she choose your technology team to run it? Worried? As a project manager or business analyst. As with most human endeavors however. Have some of the early development be conducted by your technologists at the customer’s 1.For high-profile projects. and you can lead your IT department in creating and providing valued products and services. allocate funding. Countless articles have heralded the destruction of information technology’s ivory tower and the resurrection of an IT service closely aligned with the vision and goals of its customers. you should figure out a way for IT and the customer to collaborate on each project. Of course. development. The people in this sponsorship role have to be high enough in site. and who are highly motivated to drive a successful project. consider putting your company’s reputation on the table by announcing your joint venture to the media when the project starts.
What worries them? Are there project risks you have not identified? Has the likelihood of a risk’s triggering event increased? What do these risks mean to your customer and the project? What political. demonstrate your interest in solving each issue by: Empathizing with each issue they identify Considering alternative solutions Identifying one or more workable solutions Making a recommendation based upon known constraints Helping the customer fully understand what you propose Second. As necessary. actively listen to your customer. If you need it. As an extension to your role as a communicator. Remember that if you care about people and can create positive relationships with them. Whether you have a budget for bonuses or not. you owe the stakeholders and the sponsor a levelheaded assessment of these risks. While these behaviors have helped me stay focused. A periodic phone call demonstrates that you are interested in their perspective and seek to learn their specific project concerns. Celebrate accomplishments Smile. check-in with the sponsor from time to time. handwritten note of thanks to someone is priceless. Have a party (or two). Also. determine a strategy for handling them. Consider what stakeholders mentioned when you last talked with them. escalate risks to the sponsors in your periodic status report. Start by discussing these risks with your project team. Communicate with people Start first by learning to listen. you should hold periodic face-to-face meetings with the sponsor as well. customer focus follows easily. In addition to regular project status reports to the sponsor. a heartfelt. the positive and energetic attitude you demonstrate is infectious. Routinely check-in with stakeholders. I cannot suggest you adopt them without first making a fundamental shift in how you and your IT department value customers. Although some projects feel like a death march. Once you accept this principle. or cultural forces threaten the project as you consider the ecosystem outside the project? 52 . To do so. You have to get up in the morning and declare to yourself (and the world) that your customers are your most valuable asset. talk with stakeholders more often than you have in prior projects. and assign someone to implement the strategy. a lunch is a wonderful way to rebuild enthusiasm and strengthen relationships. Manage risks You can avoid most surprises by searching for trouble in a project.4. or sustained enthusiasm. You must first understand the challenges your customer faces from their perspective. Be sure to reward those who produce results beyond what is expected of them. During your project. Build time into the project plan to evaluate risk periodically. a clarifying perspective. Send a card to someone for an innovative idea. hold open the communication pathways. Even if everyone pays their own way. Strive to be your customer’s most valued technology advisor. These phone calls help you identify new risks and issues before they gain too much steam. ask for help from them. Have fun with the project and help the project team have fun too. economic. Next Steps We all lose site of our customer’s interests at some point during a project. nearly anything is achievable. As the next step. Invite the project team out to lunch from time to time.
personnel failures. 3: Perform training and knowledge transfer Include training. if any. under budget. it can single-handedly destroy all the work you’ve done. human resources. down to the smallest details. Here are some tips to help you plan your next project and ensure that it comes in on time. Ask questions to clarify ambiguous areas. tools. 1: Analyze the requirements in detail Understand exactly what the project involves. Take stock of the project at each milestone and update the project dashboard each time. Arrange them in logical order and then start executing the smallest activity in the order of occurrence. documents — required to execute the project well before the project development starts. until each activity is complete on its own and independent of other activities. 8: Write things down Document the failures and successes of the project. high-level overview of the project and to measure the progress of project activities. Identify all relevant infrastructure — hardware. as part of the project timeline. and inferior product quality. but account for it in the project schedule and budget. and at a high quality level. This “plan B” acts are your support system when things don’t go as expected. And because time is today the most common metric to measure efficiency. 2: Map available resources Map available resources with requirements to ensure that there are enough personnel on site to complete the job. excessive time spent on activities. duplication of efforts. If the need arises. Don’t treat training as something team members do on their own time. and the design requirements. unexpected staff illnesses. unending meetings with no clear agenda and hence no clear outcome only waste time. software. 5: Estimate and allocate Assign roles and responsibilities to team members and ensure that each task has a clear owner. Use a project dashboard to obtain a visual. Finally. ensure clear communications to avoid misunderstanding between co-located 4: Identify risks Identify the potential risks and create contingency plans to deal with them. take aggressive steps to reduce the scope of the project or to avoid adding unplanned new features that require significant integration time. 6: Modularize work Break down main activities into sub-activities. Failure to assign clear responsibilities for each task can lead to overlapping responsibilities. the schedule delays caused by these events can end up costing you a fair amount of money (in addition to a possible damaged reputation). This is important. scope creep. the functional specification. Develop a backup plan to meet the project deadline in case of unexpected process or 53 . Long. Use project management tools and Gantt charts to record who does what and identify start and end dates for each activity. and supplier failures are just a few of the things that could (and probably will) go wrong with your project. 7: Avoid too many meetings Plan meetings to discuss the status of the project or on an as-needed basis to address immediate problems. Watch out for scope creep. hire professionals to clearly document the business requirements.10 tips for meeting IT project deadlines Erratic and poorly estimated timelines. 9: Beware of follow-the-sun development If there is a follow-the-sun development model (a continuous engineering environment with development happening 24/7 across the globe). it acts as historical information for similar activities in other projects.
Trying to remedy problems after they’ve deteriorated beyond recovery is the last thing you need. 54 .or cross-country-located team members. Coordinate well and regularly so that nothing falls through the cracks. 10: Escalate issues Escalate issues to management as they occur and brainstorm on solutions to problems.
it became clear that stakeholders could not agree about the specifics of several core processes. Remarkably. understood. by Alistair Cockburn. Customer gets cash from an ATM. The result is a comprehensive and meaningful story about each business process. Despite the obvious value of a guidebook’s roadmaps and narratives. “the whole is greater than the sum of the parts”. use cases often help stakeholders reach common agreement on “best practice” processes as well. As a result. A use case (different from a UML use case diagram) is a formalized story that describes how someone procedurally interacts with an existing or proposed system and they should be part of every project managers’ permanent tool set. As the team members work to describe business processes. For many stakeholders. However. While the structure of my use cases differs somewhat from Cockburn’s. use cases provide a repository of team members’ business knowledge. 10 reasons I routinely encourage analysis teams to develop use cases. Here are ten reasons why they are part of my permanent toolset. it accommodates what my analysis teams have generally needed to capture process requirements. the team captures these perspectives while identifying the related business goals. As a Introducing use cases Imagine flying to an unfamiliar foreign country where you plan to rent a car and tour the sights. Encourage common agreement about system requirements The process of writing and revising use cases produces three important outcomes in the analysis team — clarity. these written documents offer a foothold on a sometimes bewildering mountain of complex business processes. each use case spawns meaningful discussion within the group. and issues.10 reasons why use cases are indispensable to your software development project Well-written use case narratives (or simply “use cases”) offer the analysis. With use cases. The axiom. available in the download version of this post. applies here. In a facilitated group setting. and testing teams an invaluable guidebook. What does a use case look like? The document. and appreciated. 55 . The structure of this sample use case reflects a framework I’ve designed and used in several large projects. Use case narratives were most notably popularized in Writing Effective Use Cases. development. represents a detailed description of a business process. development teams often wander far from the project objectives . consensus came quickly as the team wrote and revised use cases. Group discussion exposes in-depth viewpoints that would otherwise remain hidden.at considerable expense and delay. consensus. 2. Use cases help the analysis team… 1. we information technologists too often embark on software development projects without them. As a written document. Improve communication among team members Collaborative effort enhances the success of any team. divergent perspectives are welcomed. Most people wouldn’t consider starting this trip without a good guidebook. Remarkably. and commitment. In a recent project. it is common for stakeholders to be uncertain about how a process they own actually works! Writing a use case helps stakeholders align the narrative with the details of an existing process. conditions.
and inexpensively. one use case requires a customer lookup function. While the first attempts may not be viable. As the facilitator of team meetings. the result is valuable. alternative paths. efficiently. recognize unnecessary steps. Understand business processes Software developers often lack an understanding of the customer’s business. and arranging them into some meaningful order (e. Write these terms down in front of the group and ask for a definition for each one. the analysis team may need to prioritize development work. and operational rules.by-product of this agreement. The clever 56 . the analysis team usually begins by writing “as is” use cases to describe the current business processes. iterative review and revision by the analysis team may generate a workable architecture for the new system. process exceptions. As a result. Expose what belongs outside project scope Constraints on the project may limit resources and/or the project timeline. It is easy to forget that software systems should help business people get work done — effectively. Reveal process alternatives. or that some are not needed in the first project phase. or separate project deliverables into phases. and exception paths). you will create a launching pad for the team’s imagination. 7. As the group develops a coherent and ordered set of process steps. or reach agreement on “best operational practices”. structured language that developers can readily understand. undefined terms. Also. 5. While this effort is time consuming. Recognize patterns and contexts in functional requirements Developers may view a set of use cases horizontally. Use cases also offer a valuable perspective on the stakeholders’ business goals. With this catalog. you have given the stakeholders an opportunity to declare which functions they need the most. Another use case requires a similar function but with customer data sorted in a different order. team members tend to volunteer statements that begin with the words “what about…” . carefully listen for any jargon used by stakeholders. 3. For example. As they are writing the use cases. More of these become obvious when the team considers what happens if any step in the “Main Course” fails. The “Exception Paths” often arise in a similar way. The “as is” use cases may also allow the system architect to propose high-level process flow diagrams that represent how the new system could work. To achieve these objectives.a clue to previously unidentified “Alternative Paths” to a successful outcome. and outstanding issues I always have the analysis team start a use case by developing the “Main Course of Events” (see the sample use case). Later. listen for issues as they arise. They may decide that some fall outside the project scope. or which ones they need first. Besides revealing the details of an existing business process (including business rules. Use cases help the development team… 6. assumptions. the analysis team can prioritize the use cases.. they often discover an improved process. Either way. or an item on which team members disagree? Write these down as well and later include them in a project issue log. These features provide developers with a solid foundation for developing cost-effective solutions to business challenges. you’ll add these definitions into the project glossary. the development team must understand not only the business process the software must support. You can help the analysis team by creating a catalog of the use case titles.g. Is a process step fuzzy? Is there an area that needs more research. by sub-system or umbrella process). 4. but also the process’ alternatives and exceptions. Use cases provide this information in clear. team members inevitably commit to support improved processes to both management and peers. Transform manual processes into automated processes When software is being designed to automate aspects of an existing system.
plus two more from phase two that are cheaper to build as part of phase one. after the developers installed their first software release. the developers largely ignored our use cases. The next installation was acceptable. The test scripts are now ready for use as developers complete programs. The “Assumptions”. “Main Course”. It was clear to us that 57 . “Alternative Paths”. By reading these sections. As an added bonus. however. “PreConditions”. As a good development teams writes code. Use cases provide a valuable return on the analysis team’s investment in time and resources. we challenged the developers to close the gaps rapidly.development team can find such patterns within a set of use cases. Although we created a long list of missing features. the developer understands what the role identified in the use case is trying to accomplish. and “Post-Condition”. the testing team develops test scripts from the use cases as the development team begins its work. The rooky analysis team and I compared the delivered software to our use cases. “Exception Paths”. Discover gaps between the requirements and the delivered software Some years ago. detailed functional requirements were no where to be seen. 10. the analysis team and the development should jointly consider the effect of this change. and what motivates him or her. That condition changed. I was asked to join a troubled project in which the system design phase was nearly complete. 8. and “Business Rules” sections are all source material for creating good test scripts. the development team. The “Stakeholders Goals”. use cases also reveal operational context. Lessons Learned While writing use cases may seem time consuming and tedious. the result is a foundation for work by the analysis team. As another aid to developers. Patterns are often discovered in the “Business Rules” section of use cases as well. the development team views them from a far different perspective. “Pre-Conditions”. critical features were missing. the technical manager and the development team may see cost-savings in delivering phase one software for the 12 use cases. I taught a team of functional users to write use cases themselves. Use cases help the testing team… 9. they search for coding efficiencies. and “Post-Conditions” give developers a sense of how the software will be used. Ensure the delivered software works properly While use cases significantly differ from test cases. Bundles of use cases organized into system-wide process flows become a source for writing comprehensive end-to-end test scripts. “Assumptions”. Although we completed the narratives quickly. Unfortunately. Developers may transform these patterns into universal software objects. and the testing team. Of course. and the developers had already begun writing code! In order to catch up. Prioritize work Although the analysis team may have prioritized and winnowed the use cases. the former may be used to derive the latter. While the analysis team may want 12 use cases completed in phase one.
See the previous advice — the same comment about professionalism applies.” by Patrick Andrews. that can often result in a major egg-on-face scenario. I thought. I often mistakenly thought that even if things got a little out of shape.” Maybe this manager could have handled the situation better. It’s also available as a PDF download. They left the company. unnecessary friction. 58 . Here‘s a selection of their confessions and what can be learned from each one. source-safe revision-control package — with the wrong settings. I thought. I accidentally overwrote the data files for an online project plan. There’s no point agonizing about “whatifs” after the event. This information originally appeared in the article “True confessions: What’s your biggest project management mistake?. 3: Stay on top of schedules “I simply forgot about the longstanding vacation plans of one of my crucial team members when working on the project plan. Oversights like this will cause significant. leaving me to re-create large parts of the plan from scratch. The truth is. I couldn’t believe it when. he managed to reschedule. citing my lack of management ability as one of their main reasons. I lost two people’s month-load of work because I was using an unfamiliar.” 4: Don’t second-guess the right decision “Last year. 2: Don’t mess up the simple stuff “At my last company. 5: Don’t pretend to know what you don’t “When I was quite new to project management. I had to refuse them. but I’m still having to buy him beers just to keep the story quiet. 1: Pay attention to details “I realized that I’d been sending e-mail updates to the client and spelling the name of his company incorrectly for a month. which I was pretty familiar with. it can be easy to take your eye off the ball. the error is a sign that you don’t recognize his corporate brand. but you have to make decisions and live with the consequences. and it resulted in a major cost overrun. when things are running smoothly or when you’re diverted by other priorities. Fortunately. ‘How hard can it be?’ It turned out that I had to work double-time just to stay in touch with what was happening on the project. I was asked by two of my most respected developers if they could take a two-week training course. I was embarrassed to admit my lack of experience in building embedded versions of programs. later that year.10+ project management mistakes (and what you can learn from them) Most of the project management mistakes I’ve made over the years are due to a lack of concentration.I asked some IT project management colleagues and a couple of professional rivals to divulge their professional gaffes. due to our departmental budgetary situation. there would still be plenty of time to catch up.” Try not to get overconfident. but to that client.” It seems comparatively unimportant.” The moral is to make sure to be professional even when you’re doing simple stuff like backups.
and a more important piece of work was compromised. The existing folks were part of a strong union and had adopted the “work to job description” mantra. and the contractors felt they were carrying the “slackers” (and really they were. 59 . Keep a better handle on the personal issues within the team. in order to get stuff done). 8: Don’t accept blame for another’s mistakes “A senior manager asked me to put together a feasibility study. We had quite a few new developers.” The best way to lose respect is to allow your project to mess up. 10: Don’t underestimate people issues “I had a project that nearly came apart because I underestimated the impact of people issues within the project team. Ask more questions. This created a lot of tension within the team as the staff members felt the contractors were overstepping their bounds (and really they were. I was accused of wasting scarce resources. the schedule was compromised and had to be reworked a bunch. I panicked and left out a word in my e-mail response.” Carrying the can for someone else is unfair. more frequently. Every day you fail to communicate makes the task harder. The second time around. we delivered a RAD business tool the end users never used because it didn’t provide the functionality they required. and we delivered a business analysis tool they could use and be proud of. but I was unsure what to do about it in a very macho culture where any admission of a mistake would have caused me to lose respect. in some areas). 11: Take nothing for granted “One project I was involved in went down the tubes because I didn’t check that the executive in charge had actually read the technical spec he had signed off. to get at them.” 7: Learn to say “no” “My CIO once goaded me into taking on another project when I was already really working at capacity. By then. Perhaps the manager will see this and cut you some slack the next time you need a favor.6: Don’t be afraid to admit your limitations or ask for help “I recently found that one of my projects on behalf of a defense contractor was beginning to slide.”This is such a common error because most everyone needs to learn to say “no” constructively. I kept the user and other stakeholders involved. whereas the contractors generally did whatever it took to get their deliverables done. I discovered that the manager didn’t have an authorized budget. I lost focus. To err is human — even in project management. 9: Forgive yourself and do better next time “When I was asked for an unscheduled progress summary by my CEO. and several contractors. After I’d written a detailed plan and discussed the work with several senior developers. none of it was obvious until the tension started to come to the surface. 12: Keep the end user involved “After three months and many labor hours.” Check that your senior management has read and understands the project documentation. a few more experienced folks. He then instructed a design agency to produce a product that the client couldn’t use. Even though the work was completed on time. The tool was trashed and we had to start again. A complete mess. I’m sure that my professionalism is still in question a year later.” Don’t let personal history deflect you from making the next job your masterpiece. However. It’s the only way to be certain you will deliver what they want. The whole thing was misinterpreted and blown out of proportion.” Keep the user involved from beginning to end in a development project. If you have this problem. get it out in the open today.
Learn from your mistakes to prevent bigger ones Even though it may seem as though the high-pressure field of IT project management doesn’t tolerate slip-ups. then you might be able to prevent big projects from spiraling out of control. carelessness is fundamentally different than failing while trying to do your best. If you (or that rookie project manager you’re training) can learn from your mistakes. 60 .
which then results in schedule overruns. a multitude of reasons can cause a project to go out of control. Here are some of the most common risk factors. managers leave issues unresolved for days. the trend is that many project teams think they can get started by rushing the requirements-gathering phase. possibly. scope creep can jeopardize the project. All too often. but they can be negotiated ahead of any actual development. resource requirements. If a project starts showing gradual cost overruns. I recommend that that you check project schedules daily. is also available as a PDF download. If you are developing a project using a standard waterfall methodology. 3: Budget overrun Projects that run over budget are sometimes more prone to being canceled because senior executives are concerned about cash going into and out of company coffers. This usually drives up the cost. On iterative development projects. Somehow. An even more difficult situation for a project manager surfaces when new changes are introduced after the project has been launched. the cost overruns are simply absorbed or skillfully transferred elsewhere. 61 . Lessons learned from many failed projects reveal that there was too little documentation to adequately describe the project in its broader terms and serve as a clear communication channel. which eventually causes the overall project to fail. Scope creep needs to be managed and the project manager needs to have a change control process in place to assess the impact and cost of the change and. But as the losses mount and show no sign of recovery. 2: Schedule slippage Many times. some projects are so critical to business survival that they can’t be stopped.10+ things that can send an IT project off the rails Depending upon the unique aspects of a situation. project schedules spiral out of control when dates and deliverables aren’t aggressively monitored and tracked on a daily basis. user requirements are still of utmost importance. Charvat. canceling the project may be necessary. and completion time. though. In reality. These projects are then eagerly started with incomplete requirements. 4: Scope creep When clients insist on ever-increasing changes to the product being developed. 6: Poor documentation Maintaining inadequate project documentation is cause for concern and should raise the red flag. 5: Poor planning and estimation Those projects that are poorly estimated and planned tend to fail both in cost and schedule. Note: This list. negotiate the change for a future release. which is based on the article “How to identify a failing project” by Jason P. it’s often still given a chance. deliverables. 1: Sloppy requirements Every project depends upon solid user requirements being firmly locked down prior to any work being undertaken. Therefore. any incomplete requirements will have both a negative cost and schedule impact on the project. Managers tend to start projects without relying on proper analysis and sizing and fail to consult subject matter experts or cost estimators to validate how much project work packages will cost. Failure to do so is a leading cause of project failure. I don’t know of too many project managers who can handle too many changes all at once. This means that project managers must manage their actual budgets against the planned budget and keep their stakeholders aware of any deviation.
it may be necessary to stop the project. only the vendor engineers clearly understand the limitations and functionality of the products. 62 . Yes. This doesn’t bode too well for any critical project. managers should be aware of the associated risks and plan their schedules accordingly.7: New technology Projects hat require integrating new tools and deploying new vendor applications/devices are always far more difficult because usually. In such cases. make the necessary adjustments. before moving on. though. If a project is undertaken using new technology. this results in project failure. 11: Poor testing A big culprit on any project is having either too little testing or. I have seen many projects fail simply because no one understands what to do and receives no communication regarding current progress. Both testing and quality assurance need to be built into the project from the day the project is launched. This results in delays in project schedule and could require weeks or months before the products are stable enough to be deployed. replace the project manager.if a test team is involved . in many cases . 8: Poor communications One of the biggest reasons why any project goes bad is due to a lack of communication.testing too late in the process. Inevitably. any project can be stuck with a lame duck manager. some decisions are so turned out-of-context as responsibility for them is passed down the line that they end up being made based on faulty information. 9: Poor decision-making Decisions that aren’t made at all and decisions that are delayed due to second-guessing are both risk factors. and start again. The departing manager should be given the option to provide his/her version of the story. In addition. 10: Poor project management The person managing the project may not have the skills or experience to pull it off.
Many aspects of project management require some documentation. 7: You like to execute and not plan When a client gives you a project. If you don’t want to follow good project 1: You are a poor communicator It is said that more than 50% of a project manager’s time is spent in some aspect of communication. You must rely on others for much of the detailed work when you are a project manager. what is your first inclination? If your first thought is to get a team together to start executing the work. including status reporting. phone calls. Project managers need to provide value on a project. coordinating. Some studies have shown that verbal and written communication takes up 80% of the job. you need to be able to manage people. communication plans. management processes. stand what you are doing. I am not proposing that you have to love documenting to be a good project manager. manage conflict. you must rise above the details and become more of a delegator and coordinator. If you do not want to spend the appropriate amount of time to make sure you under- 3: You prefer the details Many people like to work on the project details. you may not be a good project manager. 2: You don’t work well with people If you prefer to stay in your office and focus on your own work. But when you are a project manager. you also need to invoke the scope change management process. scope changes. If your reaction to scope 4: You don’t like to manage people You don’t have much of a project if you’re the only resource. If you are not an effective communicator (and you don’t care to be). Some project managers say they could do a much better job if they did not have to deal with people.Here’s my list of indications that you may not be well suited to be a project manager. and completing documentation. Good project managers need to spend a lot of time with clients. and team members. either. However. status reporting. all things in moderation. e-mails. you probably don’t have a project management mindset. 6: You don’t like to document things Of course.10 signs that you aren’t cut out to be a project manager You’ve all seen top 10 lists of the best traits of a project manager or the top 10 skills of a project manager. If the client raises a request that is out of scope. You will not have 100% responsibility for people. This includes meetings. We need people like that. talking to people. hold them accountable. stakeholders. you probably don’t have the collaborative ability to be a good project manager. project management is probably not for you. leadership. If you want to be a good project manager. project management is not for everyone. But you can’t hate it. etc. If that’s how you feel. but they also have many traits that make them a bad fit for the position. you are not going to get too far as a manager. don’t go down this path. you are probably not cut out to be a project manager. but you will need to show 63 . including pushing back when the client is asking for things that are not right. 8: You prefer to be an order taker If you think your job is to take orders from the customer and execute them. Many people have some of the traits to be a good project manager. But you need good processes to be effective as your projects get larger. and Project Charters. I know no one wants to be a slave of processes. 5: You don’t like to follow processes Yes. Note: These are not in any ranked order.
you need to be well organized to make sure that everyone is doing what he or she needs to do as efficiently as possible. If you’re going to manage multiple people over a period of time. 10: You think project management is “overhead” No one can feel good about their job if they think the work they perform is not value-added. 9: You are not organized People who have poor personal organization skills and techniques usually do not make good project managers. 64 . Good project managers understand the value of their work. “Yes sir.change is saying. you’re probably not the right person to be a project manager yourself. and they understand their work will result in a project coming in on time and on budget with a good experience for the client and the project team. If you think the work associated with project management is overhead and non value-added. we’ll do it” instead of going through the scope change management process. project manage is going to be a struggle for you.
and implementing sound processes for making IT investment decisions. maintain a solid enterprise architecture. beyond the control of IT. In this article. avoiding 65 . resulting in cost overruns and lost opportunities. Baseline costs are food. Cultural biases in business units may conflict with overall strategic goals. 2: Acknowledge hidden IT spending impacts Gartner estimates more than 10 percent of corporate technology spending occurs in business units. and shelter. baseline costs can be easily controlled. Many factors are involved: an understanding of the main drivers of IT costs. aligning IT spending plans with overall business strategy. 1: Control baseline costs Nondiscretionary money spent maintaining established IT systems is referred to as baseline costs. Implementing sound financial management within an IT framework is broader than simply being more efficient. controlling those costs during the project and after delivery is equally critical. Several factors contribute to increasing hidden IT spending: Flat organizational models more difficult to rein in and control Virtual enterprise structures ostensibly set up as nimble. so this is a good place to start. in which a business unit will independently decide it doesn’t need to participate in overall enterprise architecture to fulfill its departmental mission The impact of all this hidden technology spending can be profound and prevents IT from being able to control project costs. viewing IT expenditures as investments and having procedures to track their performance. clothing. Baseline costs constitute around 70 percent of all IT spending for the average organization. Renegotiate vendor contracts.10 ways to effectively estimate and control project costs Building a better bottom line is just as important for an IT department as it is for the whole organization at the enterprise level. we examine some methods to predict and manage costs. part of a sound basis for overall IT financial management. These costs tend to creep over time due to the addition of new systems. using financial resources efficiently. reexamine service levels. Business unit-sponsored systems eventually become the responsibility of IT. the idea is to maximize value and appreciation. These are the “grin and bear it” costs. This is just as important for small companies as well as large. those required just to keep things going. problems with opportunity costs. we have to spend the money but it doesn’t have to overwhelm the budget. consolidate servers. Architectural pollution from rogue projects can delay change. agile organizational constructs but without regard for policy and procedure Changing organizational authority where business unit managers are given (or take) responsibility for decentralized technology spending Selective IT outsourcing. Estimating what a project will cost is only half the battle. and practice good project and resource management. sunset older applications. meaning there’s less money available for discretionary project work. increasing the cost of support and maintenance (there are those baseline costs again). Worse yet. Think of IT projects as an investment portfolio. increasing costs and resulting in the destabilization of information and knowledge. this creep gives the appearance that IT costs are rising while the value derived from IT investments stays the same or actually goes down. By so doing you can lower the percentage of the IT budget allocated to baseline costs and keep them in line. manage assets effectively. Fortunately.
This is an effective way to control overall costs. and business process change relies too heavily on IT ownership of those business processes. infrastructure. report to senior management anticipated costs both at the start of projects and at appropriate intervals thereafter. valid. track all major development efforts throughout the enterprise and regardless of your role. This is the single biggest reason IT projects have such a high failure rate. 4: Understand IT cost estimation truths How good an estimator of project costs are you? I’m sorry to disappoint you. software licenses. immediately and vociferously.fundamental business decision-making is driven by solid information. and allocated help desk and operational staff. operations. and any IT investment should all be regularly reviewed. Collect and maintain information about all new development work underway throughout the entire enterprise and actively participate in all projects as a value-added business partner. in that it focuses us on the details. It changes over time. Getting from New York to Tokyo involves a fairly long flight. but no matter how good you think you are. making sure they still fit within the organization. Short-term thinking can also be an effective tool in project cost estimation. infrastructure. Communicate effectively and relentlessly. purchased software. to ensure maximum value is being extracted and that original ROI goals are being met. you must provide business managers with parameters for setting funding expectations and force those business managers to explain why their assumptions are 6: Implement short-term cost cutting measures Often we can control costs by putting in place tactical solutions. Don’t underestimate the future costs of maintenance and support and whatever you do. Sound like a lot? These are the costs associated with application support. Controlling these ongoing costs is critical. don’t make the classic cardinal error: Do not. Examine changes in the business and review new requests to determine whether they fit with the existing systems. a project cost before the scope has been fully defined? As an IT professional. whatever your role on a project. participate in the creation of a knowledge base of maintenance and support costs to drive future verifiable and credible estimation. you’re not that good. 66 . Keep track of project costs as the project unfolds and communicate. If you’re an IT manager. maintenance. if not virtually guarantee. at least on an annual basis. and if we don’t have it we can’t do it. 5: Leverage current system investments Applications. Remember: The cost of IT initiatives will typically exceed original estimates by an average of 100 percent. Start with the original requirements and review them to ensure return on investment goals were delivered. Don’t forget to maintain a historical record of all costs. Review vendor and product features. ongoing application costs are about 40 percent to 60 percent of the original development cost for each year in an application’s life cycle. Enterprise architecture is organic. None of us is. pad budgets in anticipation of an underestimation. your crystal ball is just as cloudy as anyone else’s. Keeping up with those changes allows for adjustments either at the periphery or by making modifications to existing components. Review embedded processes to determine whether they’re consistent with new organizational models and make changes where necessary. it’s not once and done. 3: Understand long-term application costs As a general rule. they’re necessary evils. but we can’t forget that we still have to figure out how we’re going to get to the airport to begin with. How often have you been called upon to estimate. the advice and counsel of IT is routinely omitted or ignored. as a component of baseline costs. networks. the instant you detect even the potential for an overrun. under any circumstances. Consider business reengineering. Institutional knowledge is lacking as to the result of major intitiatives.
Try to postpone capital purchases as long as possible. a strategy council to examine enterprise-level issues of strategy. Internal IT must be competitlve with external service providers. have the courage to cancel projects when that becomes necessary. Come to agreement as quickly as possible with business unit customers and sponsors as to the overall project scope and put that in writing. with little synergy between IT and the business. There are only two reasons to use external consultants--to fill a knowledge gap (we don’t know how to do something) and to fill a resource gap (we have too few to complete the project on time). This group must. This may not only provide time to negotiate better costs. Set up a business council to define priorities. IT is a discretionary expense center. These are three very different 8: Implement pricing and chargeback mechanisms I once worked for a CIO at a Fortune 500 company who decided an internal chargeback process was needed to make business units more accountable for technology costs. so why waste the budget? And outsource selectively. oversee projects. 7: Implement long-term cost cutting measures Be tactical. Just because something made sense in January doesn’t mean it still does in August. and measure (and communicate) project success across business units. Don’t underestimate the substantial resources needed to effectively administer chargeback mechanisms to ensure that business units have all the information they need and no one feels at a disadvantage. Make sure there’s an enterprise architecture. business units tend to look upon IT as a giant free toystore. of what’s required beyond that isn’t necessarily mission critical. priorities. Have an effective change management process for the inevitable “just one more thing” discussions. Negotiate the best possible rates and where possible. eliminating unnecessary costs in the process. He successfully implemented the new approach and was credited with saving the corporation many millions of dollars. 67 . because this approach is the one most fraught with political peril. politics. IT must have a clear understanding of all costs and manage the demand appropriately. These are the costs that typically are the most controllable yet too often lead to the highest cost overruns. there’s a fundamental framework (baseline costs again) but most. Reprioritize and rejustify all IT projects on a regular basis. or if one exists become a participant of. Establish. and IT loses control and becomes marginalized. there are ways to achieve both goals: making the business units accountable and maintaining central technology architectural control. of course. Put together a technical council to develop guidelines and principles for technology standards and practices. Periodic benchmarking exercises are key. He was also fired. Always control project scope. In most organizations. If your company is going to consider this. Put one in place and those same business units feel free to go to the outside to get more competitive technology pricing. Try to control human resource spending. which will limit or postpone until after project delivery the single biggest reason for cost overruns. and a successful collaboration between IT and the business drives significantly increased stakeholder value. 9: Use governance to drive IT investment decisions Too many organizations fly blind. Use client satisfaction surveys and service level agreements (a good idea no matter what the circumstances) and always show a balance between costs and benefits. Absent a chargeback mechanism. Eliminate duplicate processes and systems. Enlightened organizations understand that IT is a valueadded strategic business partner. and funding. but an idea for a less expensive solution may present itself after the project has begun. if not all. it’s hard to put the puzzle together when you have no picture on the front of the box to go by. use fixed-price agreements rather than T&M (time and materials). not everything that starts must finish. but don’t forget to be strategic at the same time.
Those folks will most likely be reassigned. Does the thing work? Does the thing provide value? Is that value measurable and consistent with the corporate mission? Some quantifiable benefits of IT work can be improved operating efficiencies. enhanced personal productivity. 10: Quantify the value/benefit proposition for IT investments Why do we do what we do? That’s not an existential or rhetorical question. How can we prove we’ve done so? Just because we’ve built a thing. Does that mean three people are going to be fired. that doesn’t mean much. so don’t take credit for expense reductions that aren’t going to happen. enhanced decision quality. IT exists to provide value. the mission of each is mutually exclusive. to participate in the achievement of organizational strategic goals. 68 .organizational constructs. and/or enabling or supporting organizational strategic initiatives. and while there may be some overlap in terms of participation. What’s most critical is to ensure the credibility of any measurements used to justify IT investments and provide after-the-fact valuations. with the resulting compensation cost saving attributable to your project? Probably not. You may be working on a project that will reduce a process from five person-days’ worth of work to two.
does your manager say “just do the work”? Does your sponsor say you are wasting time identifying risks? This disconnect is very common. You need to know that if you plan the project well (in other words. 5. Your organization is not committed Many organizations say they want good project management. . Why then. If you’re going to be good at project management. upfront planning process has value. 3. Organizations don’t value the upfront investment of time Many people consider themselves to be “doers. you have to understand that the 1. Instead. If you implement project management methodology right. Senior managers think that project management is a software tool When you discuss project management with some managers. Don’t get me wrong–tools have their place. (In other words. may utilize a tool. caused by not scaling the methodology appropriately to the size of your project. you’ll be able to manage the work more effectively. the first time you try to define the work.Top five reasons organizations fail at project management Generally speaking. However. all companies and organizations are trying to get better at project management. The words say one thing. everyone wants to start executing immediately and then redo all the work later to get it right. It’s about applying proactive processes and best practices. like the creation and management of the workplan. See if you can pick out the reasons why your organization falls short in implementing good project management discipline. You have to 69 . However. Instead. project management is about skills and discipline. but the actions say another. It’s about using common and understood templates. software tools are not the answer 2. Even though some aspects of project management. I have seen organizations that say they want to apply good project management. project management was not the problem. that is not where the value of project management is. 4. are so many organizations still so bad at project management? What is keeping most organizations from being able to effectively manage projects? I have pondered this on many consulting and training engagements and I have ranked my top five reasons below. No one wants to take the time to plan. but then are unwilling to invest the time required. Organizations don’t know how to implement culture change Most organizations don’t know how to manage culture change in general and project management in particular. paper intensive. Actually. and takes too much focus away from the work at hand. Sometimes this is a legitimate concern. does everyone say “just get going”? If you try to enforce scope change management.” Organizations can be that way as well. The problem was a misguided attempt at implementation of project management. you might have more luck convincing them to do it. if you know what you’re doing before you start). organizations recognize that there is value associated with being able to manage projects more effectively. You can’t just buy MS Project and turn people loose. You can’t just train people and turn them loose. they initially think you are trying to implement a tool that allows you to be a better project manager.) Though they may not be able to articulate it. the results will be outstanding. if it were a tool. but do the actions back up the words? For instance. there aren’t any organizations that are purposely trying to get worse at project management. You may have been burned in the past A common criticism of project management methodology is that it is cumbersome.
project management deployment ends up in the trash pile of culture change initiatives that have all failed in the past? 70 . It takes hard work and resources. Is it any wonder then. Most organizations aren’t committed to focus on the culture change long-term. and they don’t want to spend any resources to do it. that six months later.have a long-term. multi-faceted approach to managing culture change.
and there can be no misunderstanding as to whether the deadline date referred to completing the draft or having the deliverable finalized and approved. 71 . He might say it’s complete and then finish it up quickly. This is a problem. And he or she may have a legitimate concern.Beware of when “completed” activities aren’t really completed One of the primary responsibilities of a project manager is to assign work to team members and then monitor the work to see that it is completed on schedule. you might need to deal with the situation as the start of a performance problem. you need to monitor the work to make sure it’s completed within expectations. This may be a case of the team member trying to get away with the fact that the deadline date was missed. No one likes to be held accountable for estimates on something in which they didn’t have a chance to provide input. The team member can no longer hide a partially completed deliverable. The first time it occurs. It’s important that team members understand the work to be completed. However. A deliverable is “completed” in draft form but not finalized and approved. you may need to provide some coaching. but when you check the deliverable you find it’s incomplete or needs additional follow-up work. It’s very possible that a team member will not agree with these estimates. I tried to acknowledge this concern by always giving the team members a chance to validate that the estimates were reasonable. If it happens again. After you assign the work. it may also be a legitimate misunderstanding of what it means to be complete. the estimated effort. Then there is no question that the deliverable is completed. To avoid this problem. the estimated cost (if applicable) and the estimated completion date. and that the workplan leaves time for the approval process and for rework based on feedback. it may be the sign of something more serious. rather than deal with the consequences of the activity being late. If it happens again. If the team member didn’t speak up. make sure that there is an approval process for all major deliverables. This can happen for the following reasons: The activity should have been completed and the team member believes he needs just a short amount of time to complete it. because it has either been approved or it hasn’t. There may be times when you encounter a situation where the team member says that an activity is complete when in reality it isn’t quite done. Just as with the prior example. the first time it occurs you may have an opportunity for coaching. I assumed the estimates were valid. The team member may say the work is complete.
e. and there are three likely outcomes. you decide to talk to a second vendor to see if they can help fulfill the equipment order on short notice.2. a second risk B is introduced. your risk plan will need to deal with a second risk B. the probability that both risks will occur is 5% (.See effect of dependent risk by using a decision tree Most of the risks project managers face are independent of other risks.3. For example. What you really want to know is what the chance is that risk A will come true (i.000.20 * . The monetary value of risk A is $10. it’s possible that certain risks will only appear as a result of actions taken as a result of managing another risk. The monetary value of risk B is $30. outcome 1 is 20% likely to occur. If risk A comes true. which is slightly more complex. you see that the financial risks of the various outcomes are as follows: fill the entire order) and risk B will also come true (i. you also discover that there is a 25% possibility that there may be a disruption in their plant because of a potential strike. Risk A has two outcomes.e. risk B will never enter into the project. let’s say your project needs to place a large equipment order. The vendor normally has the equipment in stock. The total risk is calculated by multiplying the individual risks.25). there will be no reason to work with the second vendor and. You can use risk trees to come up with financial implications as well. and 1. there are times when risks are connected. Do you see how the two risks are related? Risk A is the primary project risk. Since there is a 20% chance of risk A. Using the decision tree. However. 1. As a part of the risk response plan.1. If you can successfully manage risk A. Figure A 72 . and outcome 2 is 80% likely to occur. However. That’s where the decision tree is used.000.. That is. 1. This is risk B. If outcome 1 occurs. Let’s look at the generic decision tree in Figure A. your primary vendor cannot fulThis decision tree shows two risks: A and B. A decision tree is a technique for determining the overall risk associated with a series of related risks. therefore. and a 25% chance of risk B. This could be risk A. You think there is a 20% risk that your primary hardware supplier may not be able to provide all the equipment you need for a large order in a timely manner. the backup vendor goes on strike). That would be the worst case scenario for you. These types of risks are easier to identify and easier to manage..
000 * . Outcome 1. this process can get complicated.500 ($10.000 * .000 ($10. you should try for outcome 2.3 (and there is only a 1% chance you can (.20) + ($30.000 * .3 has a financial risk of $3.20) + ($30.1 has a financial risk of $9.05)).25). 73 . There is an 80% chance you can hit outcome 2. Fortunately. But when you discover that one risk leads to another dependent risk (and perhaps more dependent risks). As you see. most project risks are independent of each other.20 * .000 * .000 ($10.3 because it has the smallest financial risk impact.000 * . a decision tree can help you determine the probability and impact of each risk combination.000 * .70).80). If you don’t think you can achieve outcome 1.000 * . Outcome 1.500 ($10. So you should try to achieve outcome 1.2 has a financial risk of $23. Outcome 2 has a financial risk of $8.Outcome 1.20) + ($30.05).
Likewise you can create an overall project budget by adding up the estimated costs for all of the projects. The days of the mega-project are over. cost. 2. At this point you have broken a large piece of work down into a more manageable group of deliverables and work components. Now that you have the projects identified and estimated. you can break the work up into a set of smaller projects. you must have some idea as to the estimated effort. These can also be called sub-deliverables. you can create a high-level project Gantt chart. This will not be extremely accurate. It’s better to break down huge initiatives into a group of smaller projects. You can use this simple model to define the underlying projects within the program. In this case we are actually creating a model called the Program Work Breakdown Structure (PWBS). a large IT system 74 . web. If you have work that’s too large to manage as one unique project. This may not be instantly obvious and might require some upfront analysis and research. However.that is. The trick now is to define individual projects to create each major deliverable and each work component. and duration of each project before you can proceed to the next step.Apply work breakdown structure techniques to organize a program Most of have you have used a work breakdown structure (WBS) to break large units of work into the smaller activities. you’ll need to break the large deliverable into smaller work products. This is where the work breakdown structure technique comes in. Estimate the work required for each project. For instance. Define each deliverable/work product to be a project. 4. You can determine which projects need to be executed sequentially and which ones can be executed in parallel. 6. 5. Break down large deliverables into smaller work products. Break the overall scope into the underlying deliverables. Anything not in the program scope would not be considered as a part of the program. and then coordinate and manage the multitude of smaller projects under an overall program. Define the overall scope of the program.” You can apply this same logic when structuring very large projects. The program scope defines the totality of work. You can also estimate the overall duration of the program by laying out the sequence of the underlying projects. This is the first step. could be further broken down into databases. 1. batch processes and core application logic. You can then establish a program to coordinate the individual projects so that all of the business objectives and business value is achieved. but hopefully you can get these estimates of effort and cost to around plus or minus 35%-50%. 3. These smaller activities end up being used as the basis for your project schedule. This technique is also called “decomposition” . You can’t define the underlying projects unless you understand the total amount of work required. at a high level. The technique above gives you guidance on how to define what these smaller projects look like. breaking down larger entities into more and more granular components or “breaking big rocks into small rocks. the work required to complete each project. In this case. You should be able to determine. Put the projects in sequence. Some deliverables may still be too large to create in one unique project.
Supervise larger projects with a schedule management plan As your project grows larger. Keep in mind that the approval process doesn’t include internal activity deadlines. so anyone can access and read them. However. leaving the project manager to perform a final analysis after those updates. it applies to changes in the overall project deadline. For example. a project administrator might make the initial schedule updates based on the project status reports and then send the draft to the project manager for final updates. Such feedback often comes in the form of a team member status report. such a simple process may not be rigorous enough for a very large project. some formal body may need to approve the change.) Normally. Use this section to define how you want to receive this feedback to minimize confusion with team members. Here are some specifics that a schedule management plan can define for a project: Roles and responsibilities: Describe different roles. Update responsibilities: Normally the project manager is in charge of updating the plan. you can specify the access. instead. For example. but things can be more complex on larger projects. In many projects. you may also want to do so more often. and define their responsibilities for schedule management. users update the schedule on the morning of the first workday. (The reverse is also true: Processes should be simpler for smaller projects. Access to the plan: Schedules are typically not kept confidential. It would be rare that a formal project manager would not own the schedule. A schedule management plan is part of the overall project management plan. The project manager on a larger project may need to plan ahead to understand and communicate how he or she will manage the schedule. the process used to update and manage a project schedule is pretty clear. which includes all of the documents the project manager needs to manage the project successfully. Schedule change review and approval: Define the process required to evaluate and approve proposed schedule changes. You should also describe who has the authority to accept and approve changes to the schedule. you might receive updates from your staff every Friday and assign new duties each Monday. 75 . Schedule owner: This is likely the project manager. your project management processes need to become more rigorous and structured. you might not want contractors to read it. The document used to define this is a schedule management plan. Progress feedback: Describe how you want team members to provide schedule feedback. Team members can also update the status of their assigned activities. if you have reasons to keep the schedule more secure. but after a certain threshold. The project manager may have some discretion to extend the deadline date by some number of days or weeks. Update frequency: Describe the timing of schedule updates. While you should update the schedule at least weekly. but it may also come during meetings or through e-mail. For example. However.
etc. Schedule integration: While projects normally keep independent schedules. who has access to the tools. read the schedule. and what team members can do with the tools (e. the frequency of the reports.) Reports: Define the types and names of reports you’re using to manage the project. who receives them. All of these suggested items are components you should think about and define when beginning a larger project.Tools: Describe any scheduling tools that the team will use on this project.g. etc. update schedule. Once you’ve created the schedule management plan. don’t forget to communicate the information to all interested stakeholders — and make sure you follow the plan throughout the duration of the project 76 . who creates them. You could also integrate the schedule with a higher level program or portfolio schedule. the master schedule can also serve as a roll-up of other underlying schedules..
There are a couple of ways to represent these relationships. This is referred to as a Finishto-Start relationship. the start-to-start relation- Finish-to-Start This means that Activity B cannot start until Activity A has completed. In most schedules. This activity must continue until the fertilizing starts (activity A). In many cases. The relationship only ties the start of activity A to the completion of activity B. but the plants must all be wet when the fertilizer is applied.” This finish-to-start relationship would say that we must create the Project Charter before we obtain Project Charter approval from the Project Sponsor.” Activity B is “Obtain Project Charter approval from the Project Sponsor.” The start-to-finish relationship says we need to start watering the garden (activity B) first to get the plants wet. This relationship is based on 77 . Activity A is to “fertilize the garden. Start-to-Finish Start-to-finish means that Activity A must start before Activity B can finish. This is by far the most common relationship between multiple activities. the activities themselves are placed in boxes and the boxes are connected with arrows that show the precedence relationship. Activity B is to “water the garden.“A” and “B”.” The wallpaper hangers may be ready to go (activity B). The most common precedence relationship is when one activity cannot start until another activity has finished. Example: Activity A is “Create the Project Charter. Example: Assume that you are having your walls painted in one room and wallpaper is being hung in another room. First. It only matters that there is a relationship between them. let’s assume we have two activities .Look at four ways to set precedence relationships in your schedule Part of the process of building a project schedule involves breaking down the work into smaller activities (the Work Breakdown Structure) and then sequencing the activities.” Activity B is “Hang the wallpaper. In most schedules this is the relationship that exists in almost all (if not all) cases. All four are described below. Start-to-Start This means Activity A must start before Activity B can start. Note that you can start watering at any time and you can finish fertilizing at any time. When you sequence the activities you should make sure that every activity is related to at least one other activity. Example: Let’s assume that you want to fertilize your garden.) In the PDM technique. Perhaps the most common technique is called Precedence Diagramming Method (PDM). (This technique is sometimes called Activity on Node (AON). This will ensure the plants remain wet until the fertilizer is ready to be applied. You want to minimize the total disruption and so you want to make sure both activities happen at the same time. there are three other ways that one or more activities can be related to another one. There are four possible relationships. the relationships will involve two or more activities. It does not matter what the exact activities are. However. Activity A is “Paint the walls. However. This is a very rare relationship. all relationships will be finish-to-start.” ship says that they cannot start until the painting starts (activity A).
” The finish-to-finish relationship says that the turkey must finish cooking (activity A) before the potatoes finish cooking (activity B). Example: Assume you’re cooking dinner and you want the turkey to finish cooking before the potatoes. The end times of each activity are not related and. one activity could end at a much later time than the other.” Activity B is “Cook potatoes. as long as they finish in this order. They can each start whenever they need to. This relationship is based on the end times.the activity start times. Activity A is “Cook turkey. Finish-to-Finish This means Activity A must finish before Activity B can finish. in fact. 78 .
Risk D only has a 10% chance of occurring. but let’s just consider a cost contingency budget for now. what if you’re unsuccessful in preventing some risks? In that case. Remember that the objective of risk management is to make sure that the risks do not impact your project.) If you use this technique for all of your risks.000. you would expect that you will be able to successfully manage most. there may be some monetary impact on your project. Even if it cannot be totally managed. you see that if risk D actually occurred. This is reflected in the last column. as follows: Based on the identification of these six risks. For example. The only reason you would need that much money is if every risk occurred. A risk contingency budget can be established to prepare in advance for the possibility that some risks will not be managed successfully. so the project team must really focus on this risk to make sure that it is managed successfully. However. ask for that level of risk contingency budget. The risk contingency budget will contain funds that can be tapped so that your project doesn’t go over budget. We will need two numbers for each risk: P — probability that the risk will occur. if not all. The risk contingency budget works well when there are a number of risks involved. If the risk occurs. the risk contingency budget still might not be enough to protect you from the impact. The EVM technique provides a formula for determining the right amount of budget to apply to the risk contingency budget. 79 . let’s say that you have identified six risks to your project. the risk will actually occur and cause some type of problem for your project.Create a risk contingency budget using Expected Monetary Value Risk management is the process of identifying and proactively responding to project risks. However. I — the impact to the project if the risk occurs. you can ask for a risk contingency budget to cover the impact to your project if one or more of the risks occur. (This can be broken down further into the cost impact and the schedule impact. you can’t Notice the total contingency request for this project is $33. of these risks. Therefore. which could be added to your budget as risk contingency. The risk contingency budget should reflect the potential impact of the risk as well as the likelihood that the risk will occur. the potential impact to your project is $118. hopefully its impact on the project will be lessoned through proactive risk management. you would be able to tap the contingency budget for relief. If risk C and F actually occurred. The more risks the team identifies. However.500. The question is — how do you know how much money to place into the risk contingency budget account? You can use Expected Monetary Value (EVM) as a technique to quantify the risk into budget terms. the more the overall budget risk is spread out between the risks. Generally (but not always) you will look for ways to eliminate risks or to minimize the impact of a risk if it occurs.
) Continue to brainstorm the causes by looking at more detailed explanations for each of the major cause categories identified above. you shouldn’t be concerned if there’s disagreement about whether a category holds the potential cause — just put them all up. First. Because of its shape. at this point.Use a Fishbone Diagram to attack complex problems Problems arise on many projects. or if it is a symptom. more granular causes coming off of them. This may be the actual problem or it may be a symptom — at this point you’re not exactly sure. Figure A Figure B 80 . If it’s a symptom.) Identify potential causes and group them into major categories along the “bones” of the Fishbone Diagram. A proactive project manager should have a set of problem resolution techniques that can be applied in different instances. One technique for analyzing complex problems that appear to have many interrelated causes is called a “cause and effect” diagram.) Some benefits of a Fishbone Diagram include: It allows various categories of causes to be explored. Make sure to leave enough space between the major categories on the diagram so that you can add minor detailed causes in later. It encourages creativity through a brainstorming process. You should brainstorm to identify the major categories. describe the problem on the far right side of the diagram.) Sometimes. this technique is also called a Fishbone Diagram. (See Figure B. Three levels of detail is usually the practical limit for this diagram. This arrow will serve as the backbone from which further major and minor causes will be categorized and related. a Japanese professor who pioneered the diagram in 1943. (See Figure A. The following description and examples show how the problem-solving technique works. (See Figure C. Draw a long horizontal arrow pointing to the box. (Another name you might hear for this technique is an Ishikawa Diagram. If so. The team should ask whether each category is a cause. It provides a visual image of the problem and potential categories of causes. try to identify the more detailed causes on slanted lines that hook up to the appropriate major category lines. This is named for Professor Kaoru Ishikawa. the detailed causes will have other. connect additional lines to the detailed lines.
Evaluate each major cause and the potential detailed causes associated with it. the team can begin analyzing the information. If there’s not an obvious consensus on the top areas to investigate. For each item circled.When you finish brainstorming major causes/symptoms and more detailed causes and symptoms. Now. Remember that the original list was compiled by brainstorming where all ideas are included. 81 . you should create an action Figure C plan for attaching these causes. Remember that this technique is used for complex problems with multiple causes and allows you to identify potential causes for the problem and determine which ones are most likely to be resolved. discuss how the item impacts the problem. Once you circle the causes that appear to be the most likely. you must determine which items seem more likely to be the cause (or one of the causes). This will most likely involve some high-level actions and assigning the cause to a team member to be analyzed outside of the meeting. Circle the items that are most likely and need to be investigated further. use some sort of voting system to formally narrow down the top choices with the biggest chance of success.
managers. programs. Programs are used to categorize huge work efforts into a smaller set of related projects. or administrative. Although companies may describe these terms differently. which is also the relationship that I’ve seen in companies where I have worked. The key is to see how the information maps into your organization. Portfolios are a collection of related and unrelated programs and projects. for instance. How does this compare with your definition of project management and the role of a project manager? Why doesn’t the literature spend more time describing the role of the program manager?-Dan Answer Your question gets at the heart of the relationship between projects. You may also use the term program management to define the level where you actually control budgets and staff. and portfolios. based on the type of organization and the type of project being executed. since the job typically involves the overall management of the work. I am going to describe what I believe is the most common use. The person who Projects All that being said. I think you will find plenty of literature filled with information on project management and the role of a project manager. The Project Management Institute actually defines five major types of project managers. You may use the program manager role as the first one with real authority and project management responsibility. when you read my columns on project 82 . I am focusing on projects. In these situations. people. Projects are unique in that they have a beginning and an end and have specific objectives and deliverables. and portfolios Tom Mochal answers a question about project management terminology from a TechRepublic member. It sounds as if a project manager in your organization is more of a coordinator. Projects are how all new work gets done. In other companies. the project manager had little authority and was often relegated to administrative duties. the project manager may. including new enhancements. manages a portfolio might be called a director or a vice president. in fact. etc. Administration may be considered separately or as a part of support. In general. vendors. tracking. some of which are executed sequentially while others are executed in parallel. At your company (and others). you can divide all the work of a corporation into projects (large and small) and support (ongoing operations). Consider the project manager role. be seen as more of a coordinator and have few real responsibilities other than administrative.A primer on projects. The role that you consider to be a program manager actually maps into the traditional project manager role that you read about. budget. Question I have worked at companies where a program manager was assigned to manage all major development. This is all complicated because the terms and roles might mean different things at your company. programs. and reporting. those could all be the responsibilities of a strong project manager. So. Each type is also related differently with a different set of functional. For the purposes of this discussion. many times on behalf of a department or division.. Each type has a different level of authority and responsibility in the organization.
but they are also much broader. reporting upward in the company’s management hierarchy. again. No work gets delivered at the program level. Let’s take an example of a program to send an astronaut to the moon. help start new projects. The person in charge of the portfolio is usually a functional manager. However. But all the action (hence all the literature) is still focused on the project. The program is there to help set overall direction. Instead.management. you may need to mentally translate project management issues into your role of program management. Portfolios Portfolios are similar to programs in that they encompass a set of projects. Usually. A portfolio will typically be the umbrella structure over a group of related and unrelated projects. All the work is done in the underlying projects. The moon-landing program is made up of dozens (or hundreds) of projects dealing with all the specific work required to land a human on the moon over a seven-year time frame. The portfolio may also contain support groups. a portfolio encompasses all the work associated with a specific company business unit or a specific technology. 83 . make sure the projects are progressing as they should. Programs There is not nearly as much information on program management because typically a program is defined as an umbrella organization over a group of related projects. the work is done on the projects that are within the portfolio. etc. work is not done at the portfolio level.
Sure you’re under budget. you need to collect any metrics that are mandatory for your organization. However. Make sure your metrics tell a complete story The problem with many metrics is that they’re reported in a way that doesn’t tell a complete story. and guesses.000 at this point in the project. you should collect any other metrics that are needed by your particular project. In addition. They still provide a better foundation than recollections. One way to help is to always report the metric along with the target. Start by gathering metrics that your organization requires.000. but other people accessing the information may not. while the project team doesn’t make the connection between gathering metrics and the business value received. Then add metrics that have the lowest cost and effort to collect and can provide the highest potential benefit. Collect the metrics you’ll use You don’t want to collect metrics just for the sake of collecting them. also include your expected expenditures at this point in the project. Some metrics are just prohibitively expensive to collect. Some metrics are interesting. there’s a cost to collecting and managing a metrics process. The value can be quantified in a number of areas including: Improved performance of the overall project fulfillment and delivery process Improved estimating for future projects Validation of duration. effort and quality objectives for the project Identification and communication of best practices Improved client satisfaction In general. but the work is not complete either. and leveraging the right mix of metrics is a way to gain better control of your large project. if you report your current expenditures to date. the reader still doesn’t have the context to know whether this is a good or bad situation. For instance. but don’t provide the type of information that can be 84 . If you report that your project has spent $100. leveraged for improvement. The better way to report this information is to state that you have spent $100. you estimate the final cost of the project to be $135. Of course. The project manager may be trying to create a metrics program for a large project. cost.000. these customized project specific metrics are not worth collecting for your project. The cost to collect each metric must be balanced against the potential benefit that will be gained. all discussions on performance and improvement are based on anecdotal evidence. If you report the metrics with this context.000 versus your budget of $150. The project manager should take the time Make sure the value of collecting a metric is worth the cost Just as there is some cost associated with most project management activities. metrics provide a more factual and quantitative basis for understanding how you are doing and the things that can be done better. Without at least some basic metric information. even if they are imperfect and imprecise. If the trend continued. Train your team in the purpose and value of metrics The general definition of “metrics” is not always obvious. your readers can understand what the numbers are saying. This disconnect may affect the client as well. gathering.000 to date and that according to your estimate you should have spent $110. if you don’t have a purpose for the metrics.000 so far and your total budget is $150.Four tips for using metrics on your project Identifying. perceptions and guesses. The project manager and project team may know what a given metric is telling them. or if your project isn’t long enough that you can really leverage the information. perceptions. Collect metrics.
the team should understand how to look for metrics that will provide an indication as to the state of a process or a deliverable. Educating the team and the client will help the project manager obtain better metrics with less work effort and less pushback. 85 .to explain why metrics are needed and how the information collected will help drive improvements. Likewise.
Activity resource estimating Once you know which tasks to complete. For example: PERT formula = (P+4M+O) / 6 assess the pros and cons of both methods to see which one works best for your projects. An example of a parametric estimate is: If it takes two weeks to build one house. start by using your Project Scope statement in order to understand any project constraints or assumptions that could impact your estimating. or bottom-up estimating when validating your resource requirements. PERT weighs the average of the pessimistic (P). it allows me to break down each element of the work packages into a scheduled activity by team member based on who is responsible for the package. and optimistic (O) estimates for an activity. which help define what needs to be done later. While this method may occasionally work for smaller projects. You shouldn’t need to do much guessing because you can rely upon your Organizational Process Assets.Manage project time requirements with these methods One of the most common questions I hear from project managers is: How do I determine how long a project should take? Many project managers use the old-fashioned gut check method. in which they rely on past experiences to guess how long it will take to complete a task. At this point. All of these methods are valid ways to put firm numbers in place when determining your resource needs. it will take six weeks to build three houses. these factors may include business needs or situations that have legal requirements. I find the Precedence Diagramming Method more flexible for my projects. You can base your estimates on similar activities that have occurred in the past (analogous estimating). and the Project Scope statement in your project management plan. but I tend to use process decomposition. but I recommend that you 86 . or you can estimate based on how long something typically takes to accomplish (parametric estimating). Activity definition Activity definition is when you break down a project into the individual tasks that are necessary to produce the project’s deliverables. most likely (M). To estimate an activity’s duration. Work Breakdown Structure. There are many ways to go about this. By using methods such as Organizational Process Assets. and how long you will need the resources. You can also estimate an activity’s duration by using the Program Evaluation and Review Technique (PERT) formula. expert judgment. when you need the resources during the project. Two common methods for doing activity sequencing are the Arrow Diagramming Method and the Precedence Diagramming Method. it’s time to figure out: how many resources you need. you can start defining the required activities. Activity duration estimation Many factors contribute to determining a project’s activity duration. you can also create the activity lists. The following methods can guide you in determining your project schedules with a higher degree of accuracy and help your organization efficiently plan and track projects. Enterprise Environmental Factors. Activity sequencing Activity sequencing is when you decide the order in which the project’s activities need to be completed. it becomes more difficult to accurately execute as the project grows in size and complexity. published existing data.
If there are any issues at this point in your schedule. Schedule compression will show you the impact of adding more resources to any critical path items or how running tasks in parallel can benefit the schedule. Any changes that may impact areas such as the schedule baseline or approved change requests need to be handled via this process to ensure you can track their significance on the project. By taking a more structured approach when defining and answering your questions about time management. you can perform resource leveling or schedule compression. Schedule control While schedule control is part of the necessary Integrated Change Control process. Resource leveling will help you manage your resources during periods where you may have initially found them to be over/under committed. you bring together information from activity sequencing. as well as your project schedule baseline. activity duration estimation. you will struggle with questions about what to do and when to do it. and activity resource estimating to help build your project schedule.Schedule development During schedule development. Summary During the course of any project. 87 . you must also know where your project is at any point in time. you will put yourself in a better position to come away with a plan that you can explain and execute. This step will help you define and communicate how to handle things that affect the project’s timelines.
If the project manager and team member can agree on some follow-up actions. A project manager’s second reaction is typically to recognize the problem but try to determine whether the project can still complete successfully in spite of the performance problems. After all. A “performance problem” occurs when a team member is repeatedly late. There may also be some personal problems that may require special accommodation on the part of the project manager. This discussion needs to be two-sided. In fact. The meeting should end with some concrete follow-up commitments for addressing the problem.) Of course.Don’t wait to address performance problems on a project Most project managers have had to deal with performance problems on a project at one point in their careers. Again. Once you better understand the causes of the problems. but ignoring the situation rarely works. In many cases. If a project manager believes a team member is having performance problems. the fact that a meeting is necessary will be enough to motivate the team member to do better in the future. and the project manager should have a number of examples of when the team member missed expectations. This could include actions from both the project manager and team member. and the employee has a chance to tell his or her side of the story. It’s possible that the situation will take care of itself. One of the benefits of the first meeting is that the manager can share concerns. the team member still might be causing problems — but not of a performance nature. For instance. You never know how these first discussions will progress. and that alone doesn’t raise the situation to the level of a performance problem. delivers at an unacceptable quality level. the nature of a performance problem is that a person is missing deadlines and commitments. The project manager usually doesn’t have the right level of experience or training to effectively deal with people problems. The first reaction of many project managers is to ignore a performance problem and hope that it goes away. then you might consider the 88 . sometimes that may be the case. you may be in a better position to help fix them. in many cases. Such issues are usually uncomfortable adventures for the project manager. This uncomfortable feeling usually has two causes: The project manager is usually not the functional manager of the team member and therefore does not have total authority for personnel management. people can miss a deadline for a variety of reasons. the manager can discuss his or her perceptions of the employee’s behavior and its effects on the project. Sometimes they’re difficult and don’t accomplish what you hope. but unfortunately. this usually isn’t the case. there may be some skill gaps that you can use training or mentoring to address. the team member agrees with the project manager and offers reasons for missing expectations. However. The discussion should remain fact-based. In this discussion. (If the person were meeting end dates. It’s even more problematic for a typical project manager. or chronically misses other expectations. the first reaction should be to meet with the team member one-on-one. many experienced personnel managers will tell you that dealing with performance problems are the hardest aspects of their job.
meeting to be a success. Managing people is one of the core responsibilities of a project manager. it may save you much more aggravation and pain associated with having to deal with a chronic problem later. Dealing with problem people is one of the difficult aspects of managing team members. then further escalation up to the functional manager may be necessary. If you can’t agree on a common set of follow-up activities. One of the best strategies for managing people problems is to address them early before they escalate. It’s also one that’s uncomfortable for many. If you can successfully address a problem early. 89 .
formal processes and techniques become essential. Manage documentation 9. if a major problem pops up. If you have a full lifecycle project. Let’s take a closer look at each process 1: Define the project As the project manager. Plan the work 3. A legal department and/or procurement department is usually responsible for these disciplines. Those who have worked on projects probably know that they typically include analysis and testing. These phases change depending on the project type. We’ve also excluded contract and procurement management from our list. Manage risks 7.Master these 10 processes to sharpen your project management skills Small projects don’t necessarily require much knowledge of project management or much project management discipline. are done in a parallel and ongoing manner throughout the project. but they aren’t responsible for it. On other projects. there is a major distinction to be made. during. any management-subordinate relationship requires people management. or after that time. if you were performing a research and development project. if you can master these areas. Timing and sequencing of the processes Except for the first two categories — defining the project and planning the work — the 10 major project management areas don’t fall into a sequential path. You may not have to worry about managing documentation or metrics on a small project. design. and implementation. you must use issues management regardless of what other aspects of project management you’re using before. The distinction is that it’s a project “manager” skill. or implementation. you might do only certain components. After all. Manage metrics In general. Notice that our list doesn’t include analysis. and in fact. If you were performing a study. For example. Manage scope 6. construction. testing. but the larger your project. Do you see something missing? Two processes are sometimes included as a part of basic project management: people management and contract and procurement management. Define the project 2. you can succeed in most projects. the more you’ll need to focus on all 10 processes. you could perform the full range of analysis. but we’re going to focus on 10 basic areas: 1. but not necessarily a project “management” skill. you wouldn’t be doing implementation. you must make sure that the work is properly understood and agreed to by the project 90 . But as a project gets larger. However. Different project management methodologies organize and structure these processes in various ways. Manage quality 10. testing. For example. but it’s not specific to project management. In most organizations. Analysis and testing are part of the actual project work effort (also called a project lifecycle). Manage communication 8. Manage issues 5. Processes 3 through 10 can be done in any order. the project might end after the analysis phase. design. People management is an important skill for project managers. Manage the workplan 4. project managers need to know about the management of contracts and vendors.
If the more detailed definition process results in a more refined estimate of 20. a project that requires 10. timeline. Determining whether the original business case is still valid. Think of the problems you would no doubt encounter trying to gain agreement with the client on scope. At a high level.000 effort hours might make business sense. You’ll work with the sponsor and stakeholders to ensure that the project team and the client have common perceptions of what the project will deliver. the more important it is that this information is mapped out formally and explicitly. and roles. This document should be formally approved by the project sponsor and other key stakeholders before the project team proceeds. as well as the time required to gain agreement and approval from the client. The 91 . you can use the Work Breakdown Structure (WBS). who will do the work. deadline. 2: Plan the work When you define the project. scope. etc. what it will cost. The major deliverable from this step is the Project Definition (some companies call this a Project Charter). But that is exactly the reason this definition work is done ahead of time. when it will be complete. the purpose of defining the work includes: Understanding and gaining agreement on project objectives. and what the benefits will be. risk. The effort required to define the work depends on the amount of information and the level of detail that need to be understood and documented. At the end of the definition aspect. It is also difficult to estimate the total cost and deadline date. you make sure that you have an agreement with the project sponsor on what work should be completed in this project. you determine how the work will be completed. The larger the project. You’ll take different approaches according to the size of the project. you should have a Project Definition that defines the expectations of the project in terms of objectives. the workplan for small projects can be built using a project management package like Microsoft Project.sponsor and key stakeholders before the project work begins. cost. For example. scope. costs. For example. Providing a high-level baseline from which progress can be compared and scope can be controlled. the project may no longer be feasible. you can break the project into smaller projects. All projects should start with this type of upfront planning to prevent problems caused by differing viewpoints on the basic terms of the project. Making sure the resources you need are available when you need them. you can get frustrated because of the difficulty in gaining agreement with the client on scope. The projects that are done first should then be much easier to define. If that is the case. It may be difficult to define exactly what the final deliverables look like for large and complex projects. a spreadsheet. At times. This is the most important part of defining the work and is where most of the time is spent in gaining common agreement. deliverables. and cost.000 hours. approach. a technique for looking at the project at a high level and breaking the work into smaller and smaller pieces until you can get the full picture of the work. deliverables. schedule. or cost when the work had started and the deliverables were actually being produced. risks. The projects that are to be completed in the future can be defined in detail as they get closer to execution. This involves building the Project Workplan. how the work will be completed. or even a piece of paper. If you don’t have a workplan template to use as your starting point. In this stage. Gaining agreement with the client on the processes used to manage the project. The duration required to define the work depends on the length of time necessary to discover and document the information.
the order of the work. how much effort is required. you may find it much more difficult to be successful. which you’ll use in turn to complete the Project Definition. When the deliverables. cost. you can add them by name. but it represents only your best guess as to how to complete the remaining work at any particular point in the project. you are in good shape. If it can’t. and it is clear what is required to complete the activity. If a major 92 . You then add the effort hours and the beginning and ending dates for each activity. Depending on the dynamics of your project. If you know of certain resources. effort. Your workplan is now ready to go. Some project managers think that defining and planning the work means that the hard part of managing the project is behind them. you may be in the position of having to constantly use your experience and creativity to get the project completed within expectations. the workplan is only a deliverable. As the project manager. you must implement corrective action. scope. You’ll evaluate the remaining work to see if the project will be completed within the original effort. That is definitely not the case. In many cases. During this weekly review. As you gather information about scope and deliverables. you’ll need to work on these two deliverables simultaneously. you’ve finished defining the project and planning the work. If you’re good at it. One week. managing the workplan can be one of the more challenging and rewarding aspects of project management. you add resources (workers) for each activity. assumptions. your project may be on track. and duration plans. you must evaluate the workplan on an ongoing basis (perhaps weekly) and determine the current state of the project. The relationship between defining and planning the project You may find that you can’t complete the Project Definition without starting to lay out the overall Project Workplan. this one is perhaps the most fundamental.entire team can collaborate on this exercise. and duration. you may have work assignments that are late and issues that have surfaced. You’ll never be a successful project manager if you don’t keep the workplan up to date. 4: Manage issues An “issue” arises when a problem will impede the progress of the project and can’t be resolved by the project manager and project team without outside help. the WBS has been converted to a Network Diagram. The more complex your project is. Of all of the skills of managing the project. you can use generic names as placeholders. If you don’t relish the detailed work that is required. The major deliverables in place are the Project Definition and Project Workplan. I recommend breaking down the work into lower levels until each remaining activity is less than 80 hours. It describes the work that needs to occur. The next week. you should have enough information in the Project Workplan to estimate the budget. you can’t sit idly and allow the entire project to be a week late. you’ll need to start laying out a timeline so that you can get your hands around estimated effort and duration. you’ll update the workplan with the current state of work that is completed and in progress. and approach are complete. Next. Remember. Once all of the work has been uncovered. If it can. You’ll know what work you have to complete (Project Definition) and how you’ll get the work done (Project Workplan). If not. and who is assigned. 3: Manage the workplan At this point. If an activity on the critical path is a week late. you must evaluate the resources and options available and get the project back on track. you can sequence the activities and identify dependencies between them. At this point. the more change is going to be required in your workplan over time. Instead.
and which organizations are affected. Of course. On occasion. certain expectations were set for what the project was going to produce for a certain cost and in a certain timeframe. an infinite number of things can be delivered. the sponsor should approve adding the new requirement to the project. The information is then taken to the sponsor for approval. The second component of issues management is applying specific problem-solving techniques. One important thing that all project managers discover is that having a process to resolve issues doesn’t mean you’ll successfully resolve every one. or not included in. examine alternatives. your issues resolution process and your problem-solving techniques will allow you to determine what options are available so that you at least understand the repercussions. In other instances. You and the entire team must be diligent to guard for all scope changes — big and small. the client should not expect that these items can be delivered using the previously agreed on resource and time constraints. The only question is whether you’ll actively apply issues management to the situation or flounder through indecision and uncertainty about how the issue should be resolved. sometimes it doesn’t happen so smoothly. there is no good resolution to a major problem. it will be difficult to manage scope during the project. there may be a need for items that are different from. Sometimes. Still. Both you and the project sponsor have those expectations in mind when the Project Definition is developed and approved. Everyone will then be in agreement and everyone’s expectations will have been reset. this is to be expected. Large scope changes are easy to spot. sometimes you find that you’re including them without realizing it. Scope creep means that you’re accepting small changes that end up having a significant cumulative effect on the project. your final choice is to pick the solution that causes the least harm or is the best among poor choices. During the life of a project. If this occurs. when the changes are small. 5: Manage scope Scope describes the boundaries of the project and defines what the project will deliver. 93 . Scope change management starts with scope change definition. The first is having a process to uncover issues. you have no choice but to resolve it. what data is needed. However. and what alternative would be the best course of action. and bring in people to make the best decision under the circumstances. When the project was defined. the original Project Definition. Having an understanding of one or more of these techniques allows you and your team to understand the nature and cause of the problem. Issues management has two major components.problem emerges. If the business value of the change is high enough. approved Project Definition. determine their impact on the project. Pareto charts. This includes some understanding of techniques such as Fishbone diagrams. If the project manager hasn’t done a good job defining scope. This is all part of the project management procedures that should be defined and agreed to ahead of time. what options are available. The purpose of scope change management is to protect the viability of the current. he or she is the one who should approve any changes to the original agreement. The project team will identify the new requirements and determine the impact to the project if the new requirements are included. Given a set of resources and time. as well as the incremental budget and timeline needed to complete the work. there are great alternatives to issues and your job is to help discover the best one. the sponsor is the one who approved the funding of the work to begin with. Common problems include: Scope creep. Remember. These procedures ensure that issues are recognized and resolved as quickly as possible. Therefore. and root cause analysis.
Once you identify which risks you want to actively manage. The root cause of many unsuccessful projects is poor scope change management. The project sponsor is the person paying for the project. Monitor the risk. You would leave a risk if you determined that your project would not be harmed if the risk occurred or if there was nothing that could be done to address the risk and you’re willing to take the chance that it won’t occur. As he or she is creating it. a risk is a potential problem. 6: Manage risk Risk refers to future conditions or circumstances that exist outside the control of the project team and that will have an adverse impact on the project if they occur. a risk with a high probability of occurring and a large impact on the project should definitely be managed proactively. this is the approach to take. This happens when team members think that only the project manager needs to worry about scope change management. and the work ends up being late. Proactive project managers try to identify and resolve potential problems before they occur. whereas an issue is a current problem that must be dealt with. but only the sponsor has the funding authorization to approve incremental work. Mitigate the risk: In most situations. For example. a risk that has a high likelihood of occurring but a marginal impact on the project can probably be ignored. Avoid the risk: Avoiding the risk means eliminating the condition that’s causing the problem. the client asks for new information. Since smaller projects usually don’t have long durations. They need to understand that it’s everyone’s responsibility. With that information. For example. the team spends more time with lower-level clients and end users. However. Some project team members believe that scope changes are fine if the end user approves them. 94 .End-user scope approval. and understanding the impact on the project if they occur. Move the risk: In some instances. once the project begins. a team member may be asked to create a report. If it looks more likely to occur later. On the other hand. This is not the case. the responsibility for managing a risk can be removed from the project by assigning the risk to another entity or third party. For example. the project team can determine which risks should be actively managed. determining how likely they are to occur. risks associated with a particular vendor might be avoided if another vendor is used. the team must address it at that time. you don’t proactively mitigate the risk but you monitor it to see whether it’s more or less likely to occur as time goes on. This is the science and art of risk management. The team member tries to accommodate the client. there is less opportunity for problems to develop. Larger projects usually have risks lurking just over the horizon. They can raise scope change requests. A common cause of missing deadlines is that the team members end up doing more work than required. you can invoke five general responses: Leave it. Reactive project managers resolve issues when they arise. these people can’t approve scope changes. Defining and managing scope effectively will increase the chances that your project will meet expectations. Team members not being accountable. you can develop a proactive plan to ensure that it doesn’t occur. In other words. If a risk has been identified and is a concern. Unless the sponsor has specifically delegated the approval authority. Risk management involves identifying all potential risks to the project. In this case.
but because the client or manager was surprised. Depending on the audience. If you communicate effectively and proactively. The process for building this plan includes defining all your stakeholders. all projects should communicate status. budget reports. planned accomplishments for the next period. accomplishments from the last reporting period. Clients don’t expect that a project will be risk-free. Informational. distributing management testimonials. and then deciding on a set of communications that cover as many stakeholders as possible in the most resourceefficient manner. Second. Status meetings and status reports All projects need effective communication from the project team to the project manager and from the project manager to the rest of the stakeholders. This is communication designed to build enthusiasm for your project. You communicate about adherence to the project’s budget and schedule. Status reports and status meetings need to do more than just say whether the project is on track. building a positive image.As with scope changes. First. there may be fewer options for resolution without impacting the project. If risks are identified and actively managed. Communication Plan Large initiatives. brainstorming ways to deliver that information. frequently asked questions (FAQ). it’s not because of the actual problem. the project has a much better chance of success. This is communication that provides extended information for people with a need to know more. or more politically charged. The information and presentation must be communicated with the audience in mind. Marketing. Status reports you send to the sponsor and management 8: Manage documents Many project managers take document management for granted until they’re inundated with hundreds of documents. At that time. There are two levels of communicating on projects. you need a higher and more sophisticated level of communication defined in a Communication Plan. and a project Web site that contains relevant project information. and using a project logo. current issues. you would expect that a weekly status meeting with your team would include discussions at a fairly low and detailed level. Mandatory. Examples include a document library. there is nothing inherently wrong with having risks on a project. It’s better to estimate the volume of project and project management documentation you think the project 95 . determining what information they need. 7: Manage communication Properly communicating on a project is critical for managing the clients and the shareholders. and current scope change requests. more complex. Therefore. must include an overall Communication Plan that takes a multifaceted approach to communication. Examples include publishing success stories. If risks are ignored. new risks. If they’re not kept well informed of the project progress. especially the kind that require organizational change. and legal and auditing requirements. stakeholders will necessarily be brief and high-level. This is the time you communicate everything you think needs to be known about your project. This includes status reports. you’ll find that the entire project runs more smoothly and with less conflict and frustration. Communication must be handled proactively by the project manager and must be planned and executed with a purpose in mind. in many cases when conflicts arise. the project will be negatively affected when the risks turn into issues. if your project is larger. What matters is the project management response. In fact. the communication falls into one of three areas. there is a much greater chance of problems and difficulties due to differing expectation levels.
level of help documentation. document updates get overposted and lost. This requires first breaking down the generic term of “quality” into a number of areas that define the characteristics of quality. vendors. the status reports should start with the date.will produce. Then all the status reports for a particular reporting cycle will sort together. For example. and can’t afford. However. If your team is cross-functional and includes clients. Because quality is defined by the client. However. Project managers on smaller projects don’t need to give as much thought to managing documentation. you can think of a quality computer applica- Another part of document management is understanding the types of document tools you’ll use. In other words. then each person’s historical status reports will sort together and be easier to find. completion status. The project team should strive to meet or exceed the client’s requirements and expectations. Document management involves simple and complex tasks. As projects get larger. how they’ll be organized. keywords/indexing. Should the name of the document start with each person’s name? If so. defect-free solution that doesn’t meet the client’s needs isn’t considered high quality. If you have 10 people on your team and each one submits a status report each week. If there are just a few bumps in the project. it may seem that it is completely subjective. At its worst. Sometimes there is a tendency to think that “quality” means the best material and equipment and zero defects. and confusion and uncertainty reign. the client doesn’t expect. such as a document repository. Once you’ve defined the more tangible characteristics of quality. backups. plenty about quality can be objective. Or perhaps you’ll want to search for status reports from particular points in time. A consistently high-quality product can’t be 96 . ease of understanding. A simple activity. and standard template formats. in most cases. you might define Microsoft Word as your standard document editor. On the other hand. the documentation definitively needs to be actively managed. For example. tools can be just as confusing if proper techniques aren’t used to store documents in a manner that allows them to be easily retrieved. The purpose of the quality management step is to first understand the expectations of the client in terms of quality and then put a plan and process in place to meet or exceed those expectations. retention/purging. access and security rules. document versions get out of order. these types of document management rules become more vital. establish the proper processes and rules to organize the documentation. quality is ultimately measured by the client. it’s not long before you have hundreds of documents. versioning. look-and-feel. Problems at their simplest include documentation that gets lost or is hard to find and work that ends up being duplicated. 9: Manage quality Quality is represented by how close the project and deliverables come to meeting the client’s requirements and expectations. you can look at each of them to determine how they can be measured with more objectivity. These include where you’ll store the documents. is a document-naming convention. It’s easier to organize the documents if everyone uses a common naming convention. and suppliers. This is an aspect of project management that may be supported by a tool. Quality management is not an event: It is a process and Other factors must be considered to successfully manage a mindset. a flawlessly designed. In that case. and then manage the documentation during the project to ensure that it doesn’t get out of control. tion in terms of response time. for example. However. the client can still say that the project delivered to a high level of quality. a perfect solution. naming standards. and absence of defects. documents.
Managing metrics and managing quality are related. Also determine how your project needs to be completed to be considered successful-for example. the project team must understand the expectations of the client in terms of quality and plan the activities to meet those expectations in a Quality Plan. It The Quality Plan also contains the two general quality processes: quality control and quality assurance. a good quality management process will end up taking more effort hours and cost up-front in the project. is difficult to improve the quality of your deliverables or your processes if you’re not gathering metrics. Look for a balanced set of metrics that provides indications of success in terms of cost. 10: Manage metrics Gathering metrics on a project is the most sophisticated project management process and can be the hardest. An example of a quality control activity is an inspection of each component that will be used to complete a final deliverable. you must also collect metrics that determine how well the deliverables satisfy the client’s expectations and how well the internal project delivery processes are working.produced by a faulty process. managing quality and managing metrics. for example. it is much more efficient to spot problems with the business requirements during the analysis phase of the project than to redo work to add missing requirements during the product testing. Metrics are used to give some indication of what the beginning state of quality is and whether quality is increasing or decreasing. Therefore. and cycle time. and client satisfaction. Many metrics can be gathered on a project. the ninth and tenth aspects of project management. Depending on the results. 97 . One of the purposes of quality management is to find errors and defects as early in the project as possible. you: Identify the project success criteria in terms of product deliverables and project execution. Brainstorm a set of metrics that provides an indication of the state of each success criterion. Quality assurance activities ensure that the processes used to create the deliverables are of high quality. If you want to do a good job of managing quality. All projects should be gathering basic metric information regarding cost. An example of a quality assurance technique is a checklist that contains all of the steps that a deliverable must complete before it reaches final acceptance. focusing on quality early has a large payback as the project progresses. delivery. The project team should identify and collect a balanced set that provides the most value. To determine the right metrics for your project. For example. That is. It’s also much cheaper to find a problem with. When the project is initially defined. Prioritize the potential metrics to come up with a list that provides the most value in the most cost-effective manner. However. You need a repetitive cycle of measuring quality and updating processes. So. Quality control activities ensure the deliverables produced by the project meet client expectations. a computer chip when the chip is manufactured than to replace it when a client brings the product in for service after a purchase. quality. budget and deadline expectations. effort. The Quality Plan contains completeness and correctness criteria so that the project team knows what the quality expectations are. Collecting metrics is vital to making the quality management process work. they’re usually ignored or handled poorly. you must measure. determine what your deliverables need to look like for the project to be successful. you can undertake corrective action or process improvement activities to make the processes more efficient and effective. are closely tied. However. Because metrics can be difficult to define and collect.
and make appropriate process improvement changes. metrics management is of less value on smaller projects because there isn’t enough time to capture the data. The most value is gained if the metrics are used to drive improvements on an organization-wide basis. 98 . In general. Metrics are rarely of value alone. The value comes in measuring where you are against a preferred state or agreed on target. analyze the results. Longer projects give you time to use a feedback loop.Set targets to allow you to determine success. Add collection activities to the workplan to ensure that people are responsible for the metric collection and analysis process.
and the Web is increasingly a good source. If you don’t feel an hour is enough time. Mentors are probably your most valuable resource for learning to speak the lingo. A broad understanding of a business problem depends on interviewing the people who know something about it. Leave extra buffer at the end of an interview in case a little time is needed to finish up. you have to choose a meeting place that enables the free flow of information. don’t be shy. To become familiar with these terms and concepts. try to meet outside the person’s office. If interruptions are a risk. If privacy is a potential issue. ask that they “busy” their calls. Recognizing the overhead Prepare good questions Although you may not use all of them. Pick the right place As an interviewer. For that reason. Unfortunately. there are many barriers to this flow — lack of privacy and phone interruption are examples. Enthusiasm for your questions often fades as the interviewee starts to think about his or her schedule. In order for you to understand the interviewee. Are there people above and below them in the organizational hierarchy that you should also interview? Does the business problem affect vendors or customers? If so. Be mindful of politics — the supervisor of someone you interview may feel jilted if you decide not to interview them. come prepared 99 . Prepare for an interview by learning about that domain. You should be able to identify the domain inputs and outputs. When you schedule the meeting. of preparation and follow-up. convenience or decorum may dictate a meeting in the interviewee’s office. Learn the language As business specializes. and understand the processes within it. Examine documentation. jargon develops to identify and describe its products and processes. Locate each name in an organization chart.techniques to use before and after an interview Prepare for the interview Choose the right business experts In the early stages of a project.Mining project requirements . learn existing systems. you have to understand the language he or she will use. make certain no one can hear through the walls of the room where you meet. it helps to create a flowchart or context diagram showing the entities involved in a system domain and the nature of their involvement. Consider asking a business expert to recommend a book — such books are often very valuable. I’ve conducted some excellent interviews over lunch in a noisy place. Early in the project. Schedule the meeting Hour-long interviews work well. Prepare yourself The business problem you are trying to understand has a domain. or interview people who can give you an overview of the process. There are many sources for this understanding. deciding whom to interview is a challenge. If you must meet in the person’s office. or somewhere offsite. Consider using a corporate meeting room. If the interviewee has a packed meeting schedule or supervises people. set up a second meeting with the interviewee. and consider their title and functional role. Ask the project sponsor for names of the people you should initially interview. ask the sponsor for permission to interview representatives from these groups as well. leave enough time buffers before and after your interview for the interviewee to travel between meetings. you may think a longer meeting is best. read books that describe the industry. Your local bookstore or library may have suitable books.
While you can ask the questions by e-mail. or the project is complex. When you call. perspectives. Requirements tracking refers to the process of tracking (or tracing) requirements from the beginning of the project through implementation. bring along a tape recorder. Travel distance. the interview. and interests in the context of the project. apologize for the interruption and ask if he or she has a few minutes to answer your follow-up questions. Plainly indicate the tape will not be shared with others. what often ensues is timeconsuming and unsatisfactory. review your notes as soon as possible after the interview. If they are busy. Adequate interview follow-up improves the quality of the requirements you uncover. Most people appreciate getting a follow-up phone call to clarify a few points. write down the questions you intend to ask. Ask follow-up questions It is common to have follow-up questions for the interviewee. your notes contain much of what the interview provided in value. Either way. What am I expecting this person to know? Think about the interviewee’s role. A peer’s suggestions may add great value to questions you plan to ask. By having someone else review your questions. Summarize each of the requirements you heard. Tom’s article describes “how” to interview. Next steps While preparing adequately for a requirements interview does not guarantee success. the interviewee may have intended something other than what was said. A second pair of eyes may also help you root out improper questions. In addition. “How do I know I understood the stated requirements?” Even if you recorded the conversation and listened to the tape. knowledge. you may miss important themes or lose clarity on a topic. difficult schedules. but you have to prepare “what” questions to ask. your notes probably summarize key points or identify subject areas to explore further. Invite them to review what you wrote and ask them to contact you to correct the requirements.to ask good questions. particularly if you are new to the subject area. It may help you organize and clarify questions. failing to prepare puts your interview at risk. ask for a better time to call. Ask for a second opinion When preparing for an interview. Otherwise. Start by asking yourself: What is the project scope? Rely on a project charter to provide the context for the questions you should ask. Consider asking a peer to review the questions you plan to ask. What is the context of the interviewee relative to the business need or opportunity you are investigating? Existing operational documentation may provide guidance. It’s a good practice for many projects Follow-up the interview Review and clarify your notes Good note taking is an important interview skill — whether you recorded the conversation or not. you may discover a perspective on the interview you hadn’t considered. but there are plenty of bad questions. If you did not tape 100 . Be sure to ask permission from the interviewee before you begin recording. Thirty years of interviewing people has taught me that there are rarely bad answers in an interview. the answers to your questions may have only uncovered a portion of the requirement you hope to define. Summarize your notes and ask for feedback Ask yourself. If you did record the interview. Be sure to thank them for their time and interest in the project. Send the interviewee an e-mail with the requirements as an attachment. or organizational statuses are sometimes barriers to conducting a follow-up interview. Consider recording the interview If you have only one opportunity to interview someone. Be honest and indicate why you need to record the interview.
for instance. you could even look for tools that will support this requirements tracking process. Tracking ensures that you catch any missing requirements immediately in the lifecycle. you need to have a process to track and document them throughout the project. There are other more sophisticated way to track requirements as well. It’s a good practice for many projects – especially if you’re building something from scratch. If your have a set of ten requirements for an enhancement project. Likewise. in fact. which is probably the main reason it’s not done on more projects today. If you have many requirements in a large project. if you add extra work in project design. If you check at the end of the project to see whether they’re all present. If the team assigns tracking numbers to the requirements in the Analysis Phase. ment was accounted for in each phase. but the requirements are not tracked to the actual construct components. it’s probably pretty easy to validate that they’re all accounted for throughout the project lifecycle. if you want to make sure you’re working on the right things throughout the project (no more and no less) then requirements tracking is the technique to know for sure. Not all projects need to trace requirements. 2. requirement is accounted for in subsequent project phases. 1. implemented in the final solution. For instance. In addition. However. This will save you doing extra work that’s not required. The Traceability Matrix provides a quick glance at all of the requirements and validates that they’re being considered throughout the rest of the lifecycle. It ensures that all requirements are. it will be more obvious since you won’t be able to track the design component back to a requirement. If you want to track requirements. The “X” in each box validates that each particular require- 101 . For instance. but the numbers are not utilized in the Design Phase. Smaller projects typically don’t need to. it will be difficult to track whether they’ve been tested or not and the scheme will break down. This will help you know the right person to talk to if you have questions on the requirement. a smaller benefit is that you may be able to track the requirement back to the source that it came from. This tracking can be tedious.Ensure requirements are tracked throughout a project Requirements tracking refers to the process of tracking (or tracing) requirements from the beginning of the project through implementation. if the Design Team follows up on the tracking. the whole tracking scheme will break down. It ensures that no features and functions are introduced outside of the requirements. Requirements tracking is a good practice for two reasons. it must be enforced throughout the lifecycle or else it doesn’t work. The simplest approach is to just validate that each If you’re going to do requirements tracking. something like the following table might do. it might be too late to implement any that you forgot. The easiest way to track requirements is through a simple Traceability Matrix.
in fact. the types of resources and the skills of the resources change from phase to phase. You should project out (from now until the end of the project) to make sure your current estimates for final spending and deadline are still valid. You should make sure that all of the deliverables that need approval have. Although there will be multiple gates in a project. This is a time to check that the original Business Case is still valid. Use this time to validate the priority take some corrective actions if you’re not. it wasn’t uncommon to gain a commitment to start a project and then never look back again. Here are some of the activities in the phase gate review meeting. Check that resources are available. Review project issues. The project budget should be reviewed to validate where you are within your total budget estimate. Sometimes these criteria are called exit and entry criteria and the event is called a “gate. This is an opportunity to validate that you still have the resources required to complete the remainder of the project. Forward looking Validate schedule and budget estimates. The phase gate review is a good opportunity to cancel a project that no longer makes sense. Since the process is similar. Sometimes this final approval may even take place at the phase gate review meeting. If the deliverables from the prior phase are not approved. Perhaps the interest and commitment of the sponsor has waned since the project started. Backward looking Deliverable approvals. it has become more common to set up specific points in the schedule where the project could be evaluated to ensure things are on track and to determine whether the work should continue. An increase in the project deadline or budget may mean that the Business Case no longer makes sense. Budget and schedule review. The specific deliverable reviews should have been completed earlier. Validate your sponsorship. In many projects. If they’re not. Validate that business case. you should check to see if you’re on schedule and 102 .Use gate reviews to validate that you’re ready for the next phase of your project In the past. Likewise. You should also look for any new risks to your project.” The analogy is that the project comes upon a “gate” and must get approval before the gate can be opened for the project to proceed. you can update the information at this point. This is a good time for a risk control meeting. You should validate that your prior risks are being successfully managed or you need to revise your risk plans. Gate reviews are categorized as Quality Assurance since they are focused more on the processes completed rather than reviewing any specific deliverables. You should validate that all outstanding issues have been resolved or that there’s a plan in place to resolve them. This makes the gate review similar from phase to phase and even from project to project. these reviews tend to be good candidates for a checklist. or the sponsor has changed. Over the past ten years. Review project risks. the purpose and the nature of each is similar. been approved. then the project may not be ready to enter the next phase. It’s also possible that the business value of the project has changed. however.
In other words. 103 . and you have validated the commitment to proceed. the phase “gate” is now open to enter and pass through. Once you have validated that all of the prior work is complete and correct. you should obtain a formal approval to move to the next phase.of the project with the sponsor and cancel the project if the sponsor is no longer committed.
A business 104 . What you should do: Find out if your current project is supported by a business case. one-half of all projects overrun their budgets. While not exactly scientific. what’s causing these projects to fail? The reasons are people. Get a copy of the business case and read it. Included at the end of the article are some recommended actions you can take if you find yourself on a failing project. however. It should offer a cost-benefit analysis and will often consider business risks and the impact of external events on the project. Problem # 1: Lack of a compelling business case Surprisingly enough. including business cases. This article looks at three business-related warning signs to help you recognize that a project is headed for trouble. unless you are the project manager. What are the business drivers for the project? Is the business case logical and understandable? What assumptions underlie the business case? What are the risks? What external events could affect the business case? If you do not find an understandable. Failures are demotivating at best and careerthreatening at worst. You can. There was a sense of urgency. In the software management book Peopleware: Productive Projects and Teams. And although you probably won’t be able to save the project. The dot-com crash has meant a return to business basics. So how does a project get started without a business case? This can happen because the business owner for the project “just wants it” and is powerful enough to make it happen. The stats The statistics for successful IT projects are not encouraging.and process-related issues. According to a report by The Standish Group (a business research organization). Problem #2: No agreed-upon requirements or system specification Lack of requirements can indeed be a dangerous thing. these signs can provide some early warning. Surprisingly. case is important because it provides the foundation for the project. But if it isn’t the technology. Another possibility is that IT organizations think the business unit needs it. coauthor Tom Demarco notes that the overwhelming majority of projects fail for reasons other than technology. of getting out in front of the wave. Organizations use business cases to prioritize their limited resources for those opportunities that will provide the greatest return. Of course. that’s something we’d all like to avoid. learn to spot impending problems so that you have a chance to land on your feet. you may be able to save yourself. In the last two years. compelling business case for your project. Unfortunately. the average developer is more comfortable dealing with technology-related problems and less so with people. nearly one-third of all Information Systems (IS) projects are cancelled before completion. so they build it. the reasons for failure are rarely technology related. the three most-common factors in challenged projects were requirements related. They define what the system should and shouldn’t do. If you could take action to save a project. find out why no business case has been developed.and process-related. Requirements suggest the size and shape of the system being built. Ironically. some projects get underway without a compelling business case to support them. In the Standish Group report. you may have little opportunity to affect the success or failure of the project. many Web-related projects were started without business cases because organizations believed that they had to do the project to remain competitive. you probably would.Three warning signs that your project is doomed It is likely that you will end up on a failing project at some point in your career. In addition.
Requirements management is the process of defining, documenting, tracking, and managing requirements throughout the project life cycle. This helps to ensure that the final solution meets the needs of the users. What you should do: Keep a close eye on your requirements management process. If no one seems to be managing a list of requirements for the system, or if the requirements seem to be constantly changing, then you may be headed for trouble.
Just as frightening as having an out-of-date plan is one that changes each week. I have monitored projects where each week that passed caused the end date to extend out by one week. The plan was up to date each week, but the project was still out of control. What you should do: If there is not a published plan, ask for one. If you are told that you can’t see the plan because the information is considered confidential, take that as a serious warning sign. Unless you are working on developing the next generation of the nuclear bomb, there is probably no good reason for a confidential plan. Keeping the information secret is usually an indication that the management knows there is a problem with the project and they are trying to keep it under wraps. Make sure the plan is updated at reasonable intervals. It shouldn’t be a moving target, but it must be up to date. If you can’t get a current, published plan, start to worry.
Problem #3: Lack of a current, published project plan
Amazingly enough, some projects are still being run without a project plan. This is like building a house without a blueprint. Every project is a unique undertaking and each should have a project plan. Period. Plans are essential for communications with all stakeholders, for providing an indication of progress, and for determining the work remaining to be completed. One argument against having plans is that people don’t need to be told; they somehow “know what to do.” This approach may work on a project team of one but is untenable with anything larger. People do need to be directed. They want to know the priorities. They don’t want to have to guess at what is most important. Having a plan is only part of the battle: The plan should also be kept current. Have you ever been on a project where the kickoff was held in a room wallpapered with fancy Gantt or PERT charts, only to find that those same charts remain on the walls for months or years without any change? That is not a current plan. To be current, the plan must reflect actual work completed and offer a realistic forecast of what remains to be done. Plan updates should be done no more frequently than once a week and no less often than every two weeks. The plan should accurately reflect the time and cost to complete the project. Only then can the plan be considered current.
My project is failing—now what?
What if you find yourself on a project with one or more of these warning signs of failure? Your response will depend on your personal situation. If you feel you can help the situation by taking action, by all means you should do that. Talk to the project manager, the client, or the other members of your team. Discuss your concern in a factual, nonthreatening way. Try to be as positive-minded as possible. See if you can affect the needed change. If that fails and you find you have no control over the situation, try to find a way off the project. You may be able to find a better project in the same organization or you may have to leave the organization. In either case, leave the project on a positive note. This is not the time to tell anyone how little he or she knows about running projects. If you are truly stuck on the project or if you are waiting to leave it, try changing your perspective. Treat it as a learning experience. What can you gain from the situation? What specific actions would you take to change the
situation if you were empowered? How can you avoid being on a project like this in the future? Take from the situation everything you can that will be helpful to you on future projects.
Just the beginning
These three issues all have to do with business and planning, but of course, there are many more factors that can signal a project’s demise. Next time, we will look at four factors that involve users and stakeholders and see how they can be a further warning of bad things to come for your project.
Use the tradeoff matrix to foster collaboration in agile projects
While making prudent project compromises and tradeoffs is a critical success factor in any project, in agile projects, there are certain factors that make it more challenging and more crucial. projects that actually deliver what the customer wants and needs in a dynamic and turbulent business environment. One of the key tenets of agile development is transparency. We collaborate closely with the client and other stakeholders throughout the project so that they can see the design decisions we’re making firsthand; they can also work side-by-side with us as we grapple with the tradeoffs and the compromises that are a key part of any product development project. In order to stay true to the agile concept of openness and visibility, I recommend using the tradeoff matrix as an aid to facilitation and discussion when modifying the feature set we’re committed to deliver.
In a typical linear or waterfall project, the requirements definition process is a distinct and front-loaded exercise, and much of the negotiation over features to be included is done up front. In fact, this early scope definition process, with all feature determinations and “horse-trading” done before any design or development begins, is the defining feature of a traditional project approach. Anyone who has ever worked on a traditional project knows that new features and ideas will arise during the design and development phase, no matter how frosty the “frozen” specifications are; however, in a disciplined methodology, these modifications will be managed by a change control process that will require a detailed impact analysis and the submission of all change ideas to a Control Board for further evaluation. These controls solve the problem of scope creep (which has always plagued IT projects), but the controls create unintended consequences. The process of capturing the client’s changing requirements and developing and documenting an impact analysis and then shepherding that through a Change Control Board is time-consuming and resource intensive. Also, the process is so onerous that people are discouraged from making a change request, which, in the days of frozen specs and linear projects, was considered a positive.
Using the tradeoff matrix
The tradeoff matrix is not a new idea, and it’s not exclusive to agile development. I first encountered it when training in the Microsoft Solutions Framework (MSF), a software development life cycle promoted by Microsoft for its development partners and internal teams. Although the MSF was originally offered by Microsoft to partners and developers as a program of guidance for development disciplines, it has evolved into an agile-friendly methodology that endorses many of the collaborative, iterative concepts that are common to agile methods. Every PM is familiar with the triple constraint; that is, the idea that projects are always constrained by schedule (or time), by features (or scope), and by resources (which include money and talent). When any of these elements change, it requires a tradeoff in one of the other components. For example, adding scope typically requires that the schedule be extended or that resources be added, while decreasing time or resources usually means that the feature set must be reduced. I say typically and usually because every PM has experienced the client or man-
The key insight of agile development is that change, while inconvenient for the development team, is frequently beneficial. In fact, openness to beneficial change is the catalyst for
an iteration. these decisions are made in recognition of the reality that. and where is there room for compromise? In an iterative. however. change is not cost-free. threats. the questions are the same: For the particular project element under review. is because only they know what they’re visualizing for the product. while agile projects are open to change. when clients are attempting to add features. requiring compromise in time or features. The key point is that these decisions are made by the entire team in full view of all so that issues and disagreements can be worked through. and so some features could be compromised out or “de-scoped” if necessary to meet the schedule. the resources or budget may be the fixed elements. This rejection of reality by project sponsors is a driving concept behind agile development. It’s also useful at the feature level. Depending on the project and the determinations made by the team. One reason we collaborate with the client or sponsor. tradeoff conversations are run as facilitated work sessions. as teams reach the boundaries of schedule or budget. we will choose a level of resources and adjust the features set as necessary. chosen. it becomes a much more inclusive conversation. or a specific feature. where must we conform to our previous plan. where.ager who insists on changing elements of the constraint without making corresponding adjustments in the other constraints. we’d start with the premise that: Given a fixed schedule. 108 . meeting schedule is more important than including all features. In the agile world. or adjustable. for example. In agile environments. to remind sponsors of the agreements and priorities set at the beginning. It requires the working team to recognize the reality of the project at hand by categorizing each constraint as either fixed. the drop-dead project delivery date) can’t change. such as Scrum. time-boxed development project. we will choose a ______ and adjust ________ as necessary. For example. The tradeoff matrix is often used as an internal tool for conversation and agreement by the development team. bringing them completely into the process. The tradeoff matrix can be used at the project level to document an agreement between the development team and its sponsors that the entire project will be focused on meeting schedule. the typical iteration is constrained to 30 days.g. Adjustable constraints are subject to negotiation and compromise. or resources requires adjustment to the other elements of the tradeoff triangle. and any modifications in features. It can also be used at the iteration level to ensure that all team players have a consistent understanding of the priorities and possible adjustments to this particular iteration (priorities can change from iteration to iteration. the decision that. for example).. Whether the team is setting priorities for an entire project. Chosen constraints are based on priority choices made by the team and its sponsors. The tradeoff triangle (or the triple constraint) is a useful tool for educating clients and sponsors regarding the unbreakable connection between time. and the agile PM leads the collaborative team through the process of filling in the blanks to the following sentence: Given fixed _________. and cost. scope. Also. managers. and users also participate in the conversation and have a vote in the outcome. Fixed constraints (e. for example. The use of the tradeoff matrix (depicted on TechNet) takes this conversation a step further. schedule. and that features and resources can be negotiated and changed. or miracles cannot change the fact that additional scope takes time and resources. in which sponsors. for a particular project or iteration. Agile practitioners insist on the sort of transparency that makes it clear to all participants that wishes.
Since this signoff usually signals the formal end of the project. request a formal signoff on the project documentation. I have seen complex projects that were four to six months long have a day or two scheduled for testing. unhappy staff. Here are a few things you should be thinking about when you get to the end of your next project. Early on in your project. Failure to do so will most likely manifest itself in the form of angry phone calls from irate users in the middle of the night. they may be sent back to a development pool or into the business. you should have made an agreement that determines how this will affect your end date if this situation occurs. you will likely end up with an unsatisfied customer if an issue arises at a later date. No matter what it is. be careful not to make your customers feel pressured into signing. If they do this without understanding what it means. many project managers come up just short of the finish line. 6: Analyze actual vs. and you really think you’re done. and construction phases of a project. there may be a few outstanding issues still unresolved when you get to your scheduled end date. In some cases. Failure to handle the final steps can add confusion to an initiative and may lead to customer dissatisfaction. In either case. Not scheduling an adequate amount of testing usually ends up with problems occurring during the first few weeks of an implementation. But when it comes to the end of a project. 4: Get project signoff After you’ve agreed that all the deliverables have been met. Don’t take a shortcut here and minimize the importance of testing. and many of us don’t like to do it — especially when it takes a few rounds. your customer think? Schedule time with customers to review all the deliverables and ensure they have been met. and a project dragging on longer than necessary. you’ll take on the additional risk of having a painful rollout. make sure you spend time with them and set a clear end date for when you no longer need their services. 3: Validate deliverables You’ve checked all your boxes and cleaned out your inbox. 5: Release the team Now that the project is done. Also don’t forget that you probably need to complete any performance review documents that need to be added to their file. Some of these items are purely administrative. many projects are done for their benefit. But what does 109 . elaboration. Did you really get away with only one developer/tester for 10 weeks or did you need to scramble and get more people? What about the amount of time you scheduled for your business partners? Understanding how well you hit these targets will help you better allocate resources for your next project and set more realistic expectations when it comes to a project’s duration. 1: Finalize testing Testing can be a drain on people. but many of them will help get you one step closer to ensuring that your project is successful. Or maybe they need to go drum up some work for themselves within the company. otherwise. planned Resources. where is your team going? Depending on the organization. Doing so helps ensure that everybody is in agreement on the state of the project. 2: Finalize training Users? Who cares about users? Well. you probably go through the typical inception. so make sure you have all your testing materials completed and delivered. you may treat project management as a casual practice or you may have an involved PMO.10 things you should do near the end of a project Depending on the size of your organization.
over budget? Sitting down to understand the answers to these basic questions should give you some insight into a critical area of any project. When you’re done. How much was the project going to cost? Did you come in on budget. It will help you assess how you’re progressing 110 . You also may have contracts for hardware. If you have the opportunity to send out a 360-degree feedback survey to as many individuals as possible. Whatever it is. and close out any associated financial accounts. You’ll be glad you did when your phone rings two years from now and somebody asks you to explain the rationale behind a choice you made during the course of the project. This list won’t be the same for everybody and will depend on your organization and how it implements projects. 9: Conduct a postmortem meeting What typs of risks did you identify and mitigate? What went really well that you want to ensure you do again next time? Have a meeting with all the project stakeholders and relevant participants to provide them with a forum to express any lessons learned. software. under budget. After all the hard work has been completed. 8: Ensure contract closure It’s not unsual for a project to have its own budget. when you are done you should have someplace to keep it based on the retention policy of your company. and will give you some great direction in deciding which personal growth opportunities you should focus on. 7: Archive documentation During any project. It can range from scope documents and project plans to contracts and meeting minutes.Budget. it will always make the transition to the next project smoother. request final invoices from vendors and submit them to AP. make sure that you verify that all the terms of your contracts have been met. Now what do you do? It’s important to get some feedback on your performance from the people you interacted with during the project. I would recommend it. if necessary. But if you can do them. or professional services. you’ve made sure that all the i’s have been dotted and all the t’s crossed. we seem to create huge amounts of documentation. 10: Perform a self assessment So it’s finally over.
Agile project management tips 3 .
delivering the needed features in the simplest manner without trying to speculate about the bells and whistles that might be useful sometime in the future. Alistair Cockburn. XP doesn’t scale 111 . Kent Beck. they were dedicated practitioners.Four variants of agile development methods The developers who gathered to develop the Agile Manifesto were not just theorists. which many associate with the idea of agile software development. to teams larger than 10 or so. with its need for an approach geared to speed-to-value and exploratory. and Ron Jefferies. which leads us to refactoring. It’s also a response to one of the hazards of iterative design. XP drew attention because it converged with many of the practices that developers were discovering in real project work and because its initial successes. Refactoring: Refactoring is the optimization of the internal code and architecture of software. XP is presented as a series of principles that agile developers should follow. containing the most valuable business requirements. Small releases with high-value elements: “Every release should be as small as possible. and it is not presented as a project methodology.Kent Beck Metaphor: The overall idea of the project. are codevelopers of Extreme Programming. also signers of the Agile Manifesto. innovative projects. Simplicity: The ideal of simplicity is central to XP. These elements include the following: The planning game: A recurrent workshop in which developers and customers interact in order to create and refine the “stories” that describe their project. In previous project management columns. The use of methodology and technique should be simple too. XP is unique among the agile methods surveyed here because it is focused on software development. XP developers avoid documentation. another signer of the Agile Manifesto. Ken Schwaber and Jeff Sutherland were the originators of the Scrum methods we’ve reviewed. The delivered product itself should be simple.” . who went on to create development methods based on the agile principles. unless there’s a convincing demonstration of their value to the customer. XP practitioners strive for elegance and simplicity in their actual coding practices. and it’s a key element of XP. we discussed some principles of agile development and looked at the Scrum agile methodology in detail. and it’s not well suited to virtual or dispersed teams. the broad goal told as a narrative or story to keep the technical jargon to a minimum and build a collaborative vision between developers and customers. is the architect of the Crystal methods and is an author of influential works on Use Cases. including the well-known Chrysler Comprehensive Compensation project. Now we’ll explore each of these variants of agile methods and discuss criteria for selecting one approach or another based on the project at hand. Manifesto signer Jim Highsmith has been the chronicler of the agile movement and has done the most to migrate agile concepts from the software to the project management community. other than stories and test cases. Ward Cunningham. coincided with the Internet movement. the danger that the separate iterations will be poorly Extreme Programming (XP) XP has received the lion’s share of interest among agile methods.
The consortium structure has also. Testing: The vital difference between XP testing practices and traditional practices is that XP insists that test cases for all features be developed up front. it has been proven to have some significant benefits in speed. Refactoring is a disciplined approach to rebuilding system internals to ensure simplicity.” It is focused on the concept that customers can’t foresee all the detailed workings of their system or product in advance. with its Scrum Master series of certifications. Once mastered. and optimize the product as it evolves. and customer collaboration that typify the agile methods that have become popular since the Agile Manifesto was published. each of which is iterative and incremental. XP practitioners prefer the continuous build. and Implementation phases. the 40-hour-week standard that XP espouses is consistent with the agile philosophy that creative developers do their best work when they’re committed. It incorporated many of the fundamental concepts of iteration. Design-Build.integrated and internally incompatible. has given the project management and software development communities the chance to consider these ideas and to explore their applicability to their work. customer satisfaction. elegance. Sustainable development: A reaction to the 70-hour week “death march” project that many developers have experienced. and tests. The DSDM Manual informs us that “the current step need be completed only enough to move to the next step. available to review features. and focused. As such. 112 . a popular methodology of the early 1990s. and to review. consisting of Modeling. support. with members paying an annual fee (of about $2. XP’s broad exposure. DSDM is unique among methodologies in that it follows a Consortium model. The DSDM Consortium defines DSDM as “a project delivery framework that aids the development and delivery of business solutions to tight timescales and fixed budgets. DSDM is the oldest of the recognized agile frameworks. as they work toward the customer’s goal. Dynamic System Development Model (DSDM) Developed in 1994. templates.” a nice distillation of the incremental. been a factor in DSDM’s slow adoption. iterative approach common to agile methods. energized. While the model is complex and daunting. clear. and accreditation services of the agile methods (although Scrum. is close). DSDM was developed as a structured approach to Rapid Application Development.000 a year) to remain members and retain access to the licensed use of the methodology. Pair programming: Pair programming takes the concept of software inspections and walkthroughs to the next level. Rather than periodic reviews. and the debate it has engendered. it has the most developed training. DSDM is an interlocking set of processes. team productivity. the key insight of pair programming is that two skilled practitioners can review and optimize each other’s code and each other’s coding practices. with the stories. however. Continuous builds: Going beyond the “daily build” that’s a common practice in many commercial software companies. assess. builds. it is basically a three-step iterative model. and product fitness for its visualized use. ensuring compatibility and functionality continuously as the product is created. and compatibility. incremental delivery. Available customer: XP calls for the customer to be completely integrated with the development team. tools.
says that he developed Crystal Methods to “get rid of this aberration called software engineering. people.” with preset start and end dates and with a preselected team. DSDM contrasts with some agile methods by its strict enforcement of “timeboxes. the more likely it can just retire into a conference room and build the product. but the delivery date does not. ideas have also been put forward by Mary Poppendieck and Tom Poppendieck in their book Lean Software Development (we focus on Charette’s version here). Lean manufacturing theories were highly influential in the creation of LD. This strict time management is a reaction to the ubiquitous problem of missed delivery dates for new software and products. knowledge transfer. and skills.” Since functionality can change but time and team composition don’t. interactive activity that should be designed in a way that stimulates the creativity of all participants. a cooperative. LD emphasizes four key success factors that clearly illustrate its compatibility with other agile methods: Crystal Methods Alistair Cockburn. necessarily increases. could have. the developer of the collection of methodologies known as Crystal Methods. creating a smooth “flow” of work on the factory floor. Bob Charette. They chronicled the ideas of lean manufacturing. and Crystal Methods enable that increase by presenting different methodologies and processes for different projects. the number of communication “artifacts” like written notes. The smaller the team. which categorizes features as “must have. he says. and expecting workers to contribute high skill levels and an ownership mentality. with special focus on interaction. As noted. should have. want to have (but won’t this time). optimized team and (2) projects are unique and dynamic and require methods that are specifically designed for each effort. DSDM’s emphasis on feature priorities helps teams focus on the features that deliver business value and relentlessly drive for efficiency and simplicity. Functionality may change. Similar. a survey of the lean manufacturing techniques that helped create the “Japanese miracle” of the late 1980s and early 1990s. gives us questions like “Is our model accurate?” instead of the more interesting questions such as “Is our product meeting the customer’s needs?” and “Do we have our goals aligned as a team?” In line with Cockburn’s emphasis on these questions. Crystal Methods recommend a specific methodology for each project based on three critical factors: communication density (more people means more communication channels and increased complexity). These concepts helped Toyota. DSDM is a noteworthy example of a methodology that was developed prior to the release of the Agile Manifesto but has evolved significantly to be consistent with the ideas generated by the agile community. the exemplar of these techniques. though distinct. has developed a methodology that has many commonalities with those mentioned so far.More detail on the individual processes is available at the DSDM Consortium’s Web site. DSDM employs a strict method for prioritizing requirements. As the team size increases. with their focus on eliminating waste. run through Cockburn’s work from his first articles to his current Crystal Methods development work is the concept of product development as a game. Another theme that has 113 . or written documentation. while not a signatory of the Agile Manifesto. Crystal Methods is primarily focused on communication. system criticality. community. Professor James Womack and consultant Daniel Jones published Lean Thinking. Crystal Methods is a collection of methodologies based on two fundamental assumptions: (1) teams can streamline their process as they work and become a more integrated. vault over the traditional giants of the automotive industry.” Engineering. Lean Development (LD) In 1989. without a lot of status reporting. and project prioritization.
design.” it recommends a time-boxed “whirlpool” that.Create visible customer value rapidly. Lean development is important not just for its conformance to the ideals of agile development but because the underlying philosophies of lean manufacturing have been accepted by business leaders worldwide. steady-state. like all agile methods. and build activities in each iteration. Adopt aggressiveness. This makes introduction of agile methods in a lean framework more easily accepted and presents a strategic framework that executives are likely to accept with less resistance. Summary There are other agile variants we haven’t explored here. are primarily focused on the project management element of product development. stubbornness. Some agile variants. like XP. and belief in meeting stretch goals. Build change-tolerant software. Like Scrum. Rather than the daily “Scrum. includes the analysis. and so come with existing acceptance. including Feature Driven Development and Jim Highsmith’s Adaptive Software Development. 114 . test. while others. and transition / renewal. Create only necessary functionality and no more. The agile ideas outlined here have not just created debate and discussion but have led to the crafting of a variety of disciplined. complete methodologies that bring the theories into real-world practice. are software centric. like Scrum. it consists of three distinct phases: start-up. LD is more of a project management environment than simply a software development one.
to agile approaches that address the same requirements in a slightly different way. I’ve had people in my Agile Project Management classes tell me that their perception of agile is that the key message is “everything you know about project management is wrong. cost. I’ve seen the Project Management Institute (PMI) certification evolve from an obscure and unknown credential to a virtual requirement for employment in many organizations. CMM-style shops are the following points: Sell: Evangelizing the benefits and features of agile methods and ensuring that the sponsorship exists to make this often wrenching and 115 . seem like heresy. By relating the key practices of traditional PMOs. Sliger’s key message is that both the agile and traditional project management camps have misconceptions about the ideas and capabilities of the other side. and I’m a strong advocate of adding these disciplines to the corporate toolkit to improve delivery consistency and process excellence. Some PMI-focused PMs and organizations believe that PMI and the PMBOK don’t support agile methods. such as time. not only can agile and traditional project methods co-exist. Conversely. In fact. Many IT shops have fought painful ideological and cultural battles to make the transition to disciplined project management. Many firms have committed so completely to PMBOK process flows and CMM best practices that many of the core concepts of agile development. I’ve developed project management offices (PMOs) and project management methodologies for large IT firms and service shops. We’ve also seen CMM certifications become critical differentiating factors. in my career. Capability Maturity Model (CMM)-enforced practices.” While this may in fact be the message of some purists in the agile community. especially as it applies to IT. Michele Sliger walks readers through the PMBOK and relates agile concepts to the well-known Project Management Institute (PMI) knowledge areas and process areas. and that only some tactics and approaches change. The history of project management. some agile proponents believe that PMPs are so committed to “predictive” project methods that they can’t become agile. Agile lessons learned From my experience in the trenches. but in fact. For any enterprise considering migration from PMBOKstyle project methods to more agile approaches. some of my key lessons learned for PMBOK. Sliger demonstrates that the foundation disciplines of project management remain intact as your enterprise becomes agile. however. such as “barely sufficient” documentation and change-friendliness. Sliger’s book is a must read. has resembled a pendulum. and risk management. I’m finding that these same disciplines that brought such strong benefits in project success rates can also be an impediment to agile adoption. and my counsel to firms migrating to agile methods is that. who have used CMM Level-5 certification as an “assurance factor” to help Global 500 firms feel comfortable outsourcing to far-off partners. a hybrid approach is key to success. swinging from the lax controls and do-it-yourself ethic of the early mainframe “glass room” to the rigorous methodological controls and formal software development life cycles (SDLCs) of Project Management Body of Knowledge (PMBOK). and that migration to agile automatically means abandoning PMI ideals.Five agile project management migration tips I’ve written previously about the ideas and philosophies that form the foundation of agile project management. Now that I’m working with firms to train them in agile methods and to help them migrate to agile. in most organizations and for most projects. Bridge to agile PM In her outstanding book Software Project Manager’s Bridge to Agility. especially for offshore IT service providers. I’m much more of a pragmatist.
the key to successful agile implementations. but is still also required to comply with strict PMO documentation and process requirements. business. and boost the collaborative spirit between the development team and the business sponsors? Adapt: Adaptiveness is. and should concentrate on the idea of balance and adaptiveness. By experimenting with agile methods in some key “skunkworks” projects. and looking for the right mix and balance for your organization. managers need to understand that agile teams can plan. I recently worked with a team that is experimenting with agile methods. such as both burn-down charts and Gantt charts. in fact. in my view. Reflect: Once the team has a few agile projects under its belt. your chances of a successful migration increase substantially. Many agile teams observe that the expectation of self-direction encourages them to take responsibility and ownership of their commitments. Each of your audiences will need a different sales pitch. and that we can create a long-term strategic roadmap that gives them the information they need to budget and set expectations (ideas that conflict with agile myths). that we do estimate. or competitive landscape. uses the language of “adaptive development” as his core explanatory term for these methods. honestly assessing their successes and challenges. honestly reflect on what was best and worst about these efforts. Which elements of the existing. In fact. Pilot: Many organizations transitioning to agile select specific projects. and to develop mature skills like facilitation and negotiation. and the foundational philosophies of iterative development. without requiring the organization to change its sanctioned approach without proof that agile works. and maturity that working in an agile environment can enable. Train: A robust training program for all audiences is the next key element of a successful transition to agile. dooms agile to fail as it requires even more overhead. the development life-cycle is different. the risk profile. This “double duty” is not a fair test of agile methods and. These retrospectives should focus on the process of delivery and the actual deliverables.difficult transition are prerequisites. To give a negative example. typically suitable for an agile approach due to their innovative nature and their need to quickly respond to changes in the technical. a signatory of the Agile Manifesto and the author of the influential book Agile Project Management. The language is different. 116 . minimal project management “ritual. constant customer involvement. The agile approach that any enterprise adopts must be adapted to fit the culture. and the preference of all the affected audiences. And PMO managers need to understand that their hard-won battles for discipline and consistency were not in vain. the history. and run them as “skunkworks” outside the standard PMO line of command. and is suitable culturally for the company. Development teams need to internalize the leaps in self-direction. creativity. PMBOK-compliant methods must stay. This allows development teams to quickly sidestep some of the process overhead that often accompanies SDLC-compliant programs. Jim Highsmith. and both story-driven and taskdriven project plans.” and change-friendliness must be understood and embraced for the organization to be united and prepared for the evolution ahead. because they add real value and also provide the predictability and comfort level management needs? Which agile methods have demonstrated that they can enhance the creativity and self-motivation of the team.
although they may not bring the quantum leap in innovativeness and speed that a rapid agile adoption might.Just as many firms took a long time to evolve from the “glass house” of mainframe development to the disciplined approaches of SMM and PMI. and iterative and incremental improvement is what agile methods are all about. not an event. and by preparing the way for success iteratively and incrementally. and.2 117 . they make up for that by being acceptable and comfortable. Small steps are more easily digested by all audiences. firms should expect migration to agile to be a process.
every client. my philosophy is that almost every project. Traditional PMs who work within strict Project Management Office guidelines are expected to adhere to unchanging development lifecycles. Adaptive Project Framework. to make the point that since these components vary widely from project to project and from client to client. these PMs can deliver consistent results if the goal is well-defined and that since most current IT projects evolve as they go and begin with uncertain requirements.Adaptive Project Framework: A new level of agile development In the Agile Project Management classes I teach. PMs must be prepared to adapt the project approach taken to ensure a proper fit between effort and approach. It’s my experience that very few organizations desire. his new book. such as: Risk Cost Duration Complexity as well as project variables such as: Market stability Business value Client involvement Goal and solution clarity Adaptive Project Framework Robert Wysocki. focuses on the proposition 118 . traditional project methods are not applicable. whose skill lies in following a recipe accurately and consistently. with a chef. author of one of the foundation texts on project management. traditional methodologies have no place in an agile environment. Wysocki uses an analogy to make his point that I think clarifies his ideas nicely. such as project plans and Gantt charts. one of the first things I do is write two words on the board and then tell my students that these words will be key to understanding everything we’re about to talk about in regard to agile concepts. He differentiates between the cook. The second word is hybrid. who has the experience and skills to create new recipes for each dish and to improvise within existing recipes based on the circumstances at hand. everything you know is wrong. and every organization will require us to incorporate some traditional methods into our agile approach. Effective Project Management: Traditional. to a total agile approach founded around the idea that if you’re running a traditional product development lifecycle and applying PMI standards. seems to agree. Extreme. I assure my students that while some agile proponents are almost religious in their insistence that Project Management Institute (PMI)-style. a complete migration from traditional tools. Agile. Wysocki argues that the vast majority of today’s projects include uncertainty in project characteristics that extend far beyond the requirements. or are prepared for. He cites typical project elements familiar to traditional project managers. I emphasize with my students that adapting the project approach to the specific effort at hand is a fundamental concept that underlies all agile methods. The first word is adaptive.
Adaptive PMs. In fact. Wysocki makes some strong claims for his Adaptive Project Framework. Alternatively. the client is unable to answer. Many of the attributes of Wysocki’s Adaptive Framework are familiar to us from our previous reviews of agile methods: they thrive on change. such as a repetitive effort to build a data center by copying exactly an existing facility. that an adaptive approach is most suitable. According to him. When both goal and solution are known. inaccessible. “The co-project manager model is unique to APF. is one in which the client assigns a co-PM for the length of the project. Traditional PMs are accustomed to a template-driven approach. and obtuse. Wysocki addresses this last point of client involvement indepth.” Another unique characteristic of the Adaptive Framework is its approach to requirements definition. Adaptive Projects take a different tack. traditional methods are probably the best fit. Wysocki’s book is dense. it’s often not meant as a compliment. in which the development team questions the client and stakeholders. walking through a voluminous template and often asking questions that. and Known or Unknown as the defining attributes. a hierarchical definition that begins with a top-level. Wysocki offers a requirements process based on a Requirements Breakdown Structure. according to Wysocki. he presents a clear set of values and fundamental approaches and then presents a detailed execution model that walks practitioners through the process of implementing his ideas. many agile approaches offer a story-driven approach to requirements definition. He notes that for the first time the 2007 edition of The Standish Group’s famous Chaos Report cites “lack of meaningful client involvement” as the number one reason for project failure. but in the best sense of the word. His book is not meant for skimming. with decision authority for the client side of the engagement.the solution is understood. This leads him to assert that the best project management structure.” Wysocki notes. rather than offering vague concepts and high-minded advice. but instead intended to imply that the book is difficult. strategic project goal and then progressively decomposes that goal into a four-level structure: Requirements Functions Sub-functions Features He makes a nice distinction between the Requirements Breakdown Structure and the traditional Work Breakdown Structure: “The RBS answers the question ‘What are we going to deliver?’ The WBS…answers the question ‘How are we going to deliver it?’” Conclusion When a reviewer calls a book dense. It is in those situations where both the goal and the solution are unknown and where the expectation is that through continuous refinement and incremental delivery. every page rewards patient readers with valuable insights and stepwise methods for applying his framework. such as the Robertson Volere Requirements Specification template. “and is a critical success factor for such projects. and they are client driven and have an inherent expectation of deep client involvement. projects that follow the 119 . these variables will be refined and discovered. thrive in environments where the project goals are not yet completely specified and may evolve as the project progresses and where the solution is speculative. due to uncertainty or limited technical background. he offers a “magic quadrant” that illustrates his point by pointing to Goals and Solutions as key variables. The most important characteristic is that both parties are equally vested and responsible for the project. they learn by iterative delivery and discovery. for those high-uncertainty projects that warrant an adaptive project approach.
Adaptive Framework deliver projects faster. it’s clear to me that Wysocki’s Adaptive Project Framework is a valuable addition to the PM literature and takes the ideas of agile development to another level of reality and pragmatism. While I’m not prepared to endorse these claims. with higher quality and better business value. cheaper. He goes so far as to state that his approach delivers successful projects every single time without fail. 120 .
innovative approach to project management. denies that stakeholders deserve visibility into the project for which they are paying and on which they are relying for added business value. One of the unspoken misfortunes of traditional project methods is that the PM and the team typically start out behind and in trouble and get progressively deeper and deeper into “task debt. In traditional project management. for PMOs and managers comfortable with traditional tracking and reporting methods. have instead led some PMO teams to apply tighter discipline to project reporting and change control. which lists all the features that make up the entire product the Sprint Backlog. but you’re only 42% complete… what went wrong?”). the reporting expectations are clearly defined. we obviously need to keep the team and customer informed on our progress. The reporting techniques we apply must concentrate on value delivered. No project manager (PM). not to tick tasks off a list. In Scrum. This often turns the project plan and the Gantt chart (rather than actual delivered product features) into the central indicators of project progress. this becomes a cultural transition challenge as well as a simple project visibility issue. different agile methods have different standards. 121 . in the form of features developed or requirements satisfied. We frequently find ourselves pitted against our own predictions as we report to our customers (”you said you’d be 56% complete. which illustrates (usually in the form of a trend graph) the work we’ve actually “burned through. which details the differences between the Product Backlog and the Sprint Backlog the Burndown report or chart.Agile reporting methods for project managers Before we explore specific agile reporting methods. also applies to reporting. it’s important to return to fundamental principles and refresh our motivations for project status reporting. we often spend a significant amount of our development time either trying to predict our development path or trying to track our path against these predictions. Past project failures.” giving us a realworld view of the team’s progress Using Scrum as an example. Many organizations have invested significant energy into the creation of Project Management Offices (PMOs) and have defined strict guidelines for the reporting processes required to keep managers and other stakeholders informed. new techniques can be disorienting and intimidating.” which we apply to project documentation. and avoid getting us dragged down into the “task check-off” mode that traditional methods often enforce. For organizations accustomed to the project plan and Gantt chart. the Changes report. Any disagreement is one of degree and focus. we typically create four reports at the end of each iteration: the Product Backlog. rather than pointing to the need for a new. agile or traditional. This forces PMs to include more granular task detail in their plans and Gantt charts and risks turning them into project bureaucrats rather than team leaders. which include the features we’ve committed to deliver in the next iteration Scrum Agile reporting techniques The agile concept of “barely sufficient.” destroying the team morale and diverting the PM from productive leadership activities to justification and detail obsession. Project failure is interpreted to prove that the process wasn’t rigorous enough. but it’s key to remember that we’re here to build business value.
turning that tool from a task-focused to a feature-focused device. I encourage this practice. In fact. Many agile teams keep it on a whiteboard. For more detail about Backlogs. which are easy to move. which are designed specifically for agile development projects. Unlike a comprehensive Business Requirements Document. a relative size estimate. agile teams know that they. narrowly focused on the features we’re trying to complete in the current iteration. as seen in traditional project management. sticky notes. or in Excel. features requested are simply listed in a one-line description. All the stories. Sprint Backlog In agile development. or on the wall in the form of a bunch of sticky notes. read the Scrum Alliance’s excellent article. out of all those uncovered. When we’re starting out. and any elaboration or further definition. as discovered during conversations with customers. In the effort to make agile seem familiar to customers accustomed to traditional project plans. are solid alternatives to Microsoft Project. Agile teams are committed to encourage and create beneficial changes to the feature set in order to produce the end result that delivers the most customer value. and some indication of priority. We also 122 . reprioritize. the Backlog is often characterized as “the project plan for the entire release. the initial Sprint Backlog tells us which features. As long as project teams can resist the urge to start decomposing features into granular tasks and remain focused on the delivery of valuable features instead of task activities. and the team’s capabilities and speed — that’s why the Sprint Backlog is such an integral element of the process. we’ve selected to tackle in the first iteration. the more agile PMs can utilize familiar tools without sacrificing agile concepts. each iteration reveals new realities about the product. What- ever tool is used.” Some teams — to satisfy their stakeholders’ desire to remain in the comfort zone of traditional practices — will use familiar tools such as Microsoft Project to track the backlog. so that they own their commitments and are updated regularly in Sprint planning meetings to reflect the reality of the team’s progress. we modify our plans to take into account our empirical learnings about the product. our processes. are likely to think of valuable additions or extensions to the product as they are exposed to it and have a chance to see how it works. are kept separately from the Backlog and are typically “owned” by the developer who has taken responsibility for each feature. In addition. and realities of development. The Sprint Backlog is a subset of the Product Backlog. may be the representation of the Backlog most consistent with agile concepts. the less resistance and methodology competition they’re likely to encounter. or features. Stories to be developed in the current sprint are selected by the team. As we work through our iterations and learn about the complexities. teams can misjudge their ability to deliver or the complexity of features for many technical and organizational reasons. Backlog formats vary widely based on team preference but typically record at least the feature description. Tools such as ScrumWorks and VersionOne. agile PMs must remember the central agile idea of simplicity and not make the Backlog more complicated than necessary. the Backlog is a list of features stakeholders have told us they want. interactions. you’ve uncovered so far in your conversations with the product owner and other stakeholders are listed and prioritized here. rather than the entire feature set for the entire product. put simply.Product Backlog The Product Backlog is the master requirements repository for the entire effort. with the added advantage of assisting PMs in educating and migrating stakeholders to agile terminology and concepts. or their stakeholders. I’m resistant to making the agile migration into a cultural tug-of-war. and even wad up and throw away. Changes Report As we’ve learned in traditional project work. change.
what’s left. as customers and development teams worry about our ability to control and track changes to a project in progress. ery. and they are always subject to the approval of the Product Owner (in Scrum) or whomever is designated with decision authority from the client side. Upwardsloping trend lines aren’t necessarily bad. True. they can add charts for whatever they need to track. While conversation is the best vehicle for encouraging clarity and relationship.want to avoid cumbersome change control processes that discourage change and make every new idea seem like a defect in requirements gathering. and draw a trend line between these points. we can add. Net Present Value. but they’re always worth seeing. Burndown Chart The Burndown Chart is a simple trend graph that illustrates work performed over time. it may be the most critical. delete. As agile PMs. it’s probably better suited for a spreadsheet or outline list rather than a wall full of sticky notes. The Changes Report is a key instrument for helping teams and stakeholders gain comfort with the agile change process. This is one area that plagues agile migration projects the most. our methods should always support the imperative for communication and collaboration. I favor the Changes Report from bitter experience of disagreement and “convenient memory” when changes requested by clients impact schedule or budget commitments. but we keep track of them in our Changes Report. Most important is to maintain open collaboration and communication and to avoid making the process more important than the product. AgileEVM. such as defects or customer acceptance. Summary We’ll leave the conversation about the Daily Meeting for another day.g. It should have enough detail to track the change requestor and the business justification for the change to allow stakeholders to make informed decisions. charts on the wall of a “war room” can make it clear to all who pass exactly what the team has accomplished. except to say that. as they can indicate beneficial changes in direction. by the comments about “Big Visible Charts” made by agile pioneer Ron Jeffries. and how you’re doing against commitments. A quick look at the chart also tells us how far you still have to go. or modify features while the project is in motion. it can also indicate places where the team is getting stuck or incorporating lots of changes. Agile teams use a relative-size approach (e. While not included in every implementation of Scrum. story points) to estimate the work to be done. This requirement for visibility is emphasized 123 . plot the number of points developed as time passes (beginning with the first sprint and all features still to be developed). and can augment this minimum reporting set with reports on velocity. Agile teams should be agile in reporting as well as deliv- Because this report often acts as a rough traceability document for audit or budget retrospectives.. of all the reporting mechanisms of an agile team. or many other status items.
tracking progress. accepting or rejecting them.Agile drivers for new project management tools If you believe in the concept of the tipping point. the actual coding or development can’t be automated or “tooled”. One of the central tenets of the Agile Manifesto is the statement that “We value processes and tools. As Jim Highsmith repeatedly reminds us. probably don’t require or benefit from agile methods. to demonstrate to them that I’ve thought through the tasks required to deliver the project results. this extreme interpretation misses the point. and they expect to see written change control documents when the scope evolves. When I manage projects as a contract PM. the most difficult element of migrating to agile is acclimating to new techniques for planning work. That’s not to say. and following their thread to the next unique idea. When we build software or products in an experimental mode. integration. it’s important to refer to the agile concepts of experimentation and uniqueness. only human beings can go through the iterative. at its core. Every project sill requires design. as well as their clients and managers. These statistics illustrate that agile has gone from a radical. and these common elements can be The tools define the project It’s also important to remember that.” The distinction between operational and experimental projects In addition. other than a packet of sticky notes affixed to the wall. for many development teams. that every element of the agile development process is unique. Operational projects that incorporate existing project plans and produce repetitive results. the tools define the project. my clients often want to see the work 124 . this phrase has been misinterpreted to mean that agile developers must reject tools and automation of the development process and that the use of any tool to assist in tracking progress or managing tasks. the development of a new silicon chip design does. focused on fitting the process to the type of project at hand. be as agile as you want in your development activities. automatically brands a team as “un-agile. like the building of the twentieth semiconductor fabrication plant. but you still need to show me a project plan and a Gantt chart to reassure me that you’re on track. the guiding principle is the same: What’s the “barely sufficient” solution that fulfills the functional need without adding unnecessary process and without sacrificing the ideals of simplicity and flow that guide agile development? breakdown structure. fringe technique to the dominant methodology since the Agile Manifesto was first published back in 2001. For many managers. This distinction between operational and experimental projects is key. the client’s attitude is “I don’t care what you developers do in your ‘war room’. which has led to the myth that agile developers aren’t allowed to use pens or paper. the migration to agile software development has tipped. however. According to the latest report on Agile Development Tools by Forrester Research. but we value individuals and interactions more. or project plan. speculative process of trying out ideas. testing. in contrast to the 13% who profess to using a waterfall approach (the remainder use no formal methodology). usually constructed in Microsoft Project.” Like the extreme interpretation of the comments in the Agile Manifesto regarding documentation. agile development is. They look for the Gantt chart to see the effort defined against a time line. and monitoring. Often. When agile developers decide how much documentation to write or what sorts of tools to apply. and integrating changes into the project scope. 56% of the survey respondents use agile or iterative development methods.” Like many of the bold statements that make up the manifesto.
Conclusion This article is not intended as a review of these tools. Tools that allow for frequent transitions in the plan and that can instantly indicate what the team has learned about what will or won’t work are required. Speed and agility are factors Both speed and agility also cry out for new tools. new tools that can reassure them that they can still keep their finger on the pulse of development are key reassurance factors that go a long way toward easing the transition. are being automated by vendors eager to produce the corollary of Microsoft Project for the agile world. in the report noted above. and VersionOne. in which features. for Tracking and Reporting than Traditional Developers. the old Gantt-charton-the-wall technique won’t work. “Scrum and Other Agile Practitioners Use Different Techniques 125 . capable tools that can make the work of agile development more efficient and visible. CollabNet. Automation in agile development In fact. Many vendors. does a great job of evaluating the many vendor offerings in this space and guiding readers through the selection process. the Burndown Chart. but instead to discuss the agile drivers and concepts that create the need for new project management tools in the first place.” the Product and Sprint Backlog. and other tracking and monitoring tools are obvious candidates for automation. the ability to keep the entire team informed on the progress against task and feature development is critical. from IBM and HP to newer entrants such as CollabNet. agile development calls out for automation due to some of its inherent characteristics. Frequent testing and integration also drives the need for current information that is easily accessed by team members. this obviously becomes even more important. Forrester. during the migration to agile. from its free ScrumWorks Basic package (which offers the foundational capabilities to track and manage a product backlog) to its TeamForge product (which presents a complete team development environment designed for large-scale. Many of these vendors offer free trial versions or limited-time trials of their complete packages. sequences. The agile tool space is populated with mature. distributed development efforts). In distributed teams. Agile tools As I noted in a previous TechRepublic column. In an agile project. Agile teams need to discard the myths that fool us into believing that we must either adapt the old tools or use only whiteboards and Post-it notes to control our project efforts. without violating the fundamental tenets of agility. are producing products that offer these capabilities. and more.automated and. so they can understand the status of all elements of the product at any moment. Rally Software. for example. has a suite of tools that spans the gamut. managers are often disconcerted by the change in status reporting tools. Because stories or features are often decomposed into tasks and frequently parsed out to different team members for development. in fact. unless you want to assign someone to put it up and tear it down hourly. and tasks can change rapidly and items can be added or subtracted from the scope daily (or even hourly). As we discussed earlier. the Change Report or Delta Table. contrary to the myth that agile teams reject tools.
from estimating to the discovery of requirements. few new discoveries are expected. to make adjustments and decisions on the fly. and predictable outcomes are essential. prescribes every element of the trip with detailed checklists and procedures and requires a central control agency to direct every decision and procedure. For those trips in which discovery and exploration are the goal. I discussed various concepts regarding the application of agile project management methodologies. and to explore byways and detours that may add significant Like all the agile approaches to software development and project management. “…but the people who prevail are those who figure out how to change to a system of independent agents operating under an appropriate set of rules. and. roles. and artifacts. such as those in which the origin and destination are well-known and unchanging. by following a few simple. cess and then disengages until the end product is delivered. to determine the route as she goes. while convenient and appropriate for certain types of trips. but I have yet to explore the specifics of any of the agile approaches. in contrast. Scrum builds on a few fundamental concepts. Teams of self-motivated. talented teams try out their ideas. innovative products by entrusting them to use their talents and intelligence to devise their own direction. allows the traveler. well-understood rules. Traveling by car. in her introduction to Ken Schwaber’s book Agile Project Management with Scrum. based on the new information generated value to the trip and the outcome.Get an overview of the Scrum agile project approach In previous columns. Fundamentals of Scrum Scrum is an example of a structured agile methodology that. Through the independent. The concepts are: In experimental or exploratory projects. iterative approaches that present the client with progressive deliverables and then make adjustments and course corrections as the work proceeds. independent actions by operators making decisions as they go and applying a few simple “rules of the road” are more likely to deliver satisfying results.” In action. makes a very apt analogy. 126 . self-directed application of these rules.” Poppendieck notes. such as Extreme Programming and Adaptive development. Air travel. roles. by applying a few simple “rules of the road.” enables teams and their clients to develop complex. present them to the sponsor for comment and validation. She compares traveling by airplane with traveling by car. and tools. Constant and close collaboration with the client and sponsors of a development effort is more likely to succeed than projects in which the client participates in a front-loaded requirements proThe point of the analogy is that. Mary Poppendieck. while predictive and rigidly controlled processes are totally appropriate for trips in which the path is well-known. So let’s take a more focused look at the agile variant that is gaining a lot of traction: Scrum. skilled practitioners are more likely to succeed and to feel rewarded and productive in self-directed teams in which individuals take ownership of specific deliverables and then devise their own methods of achieving them. Scrum is based on a few simple rules. predictive methods are less likely to be effective than incremental. I’ve mentioned some of the variants of agile methods. “Some might try valiantly to make control systems work by applying more rigor.
three key activities or “ceremonies” that participants perform. who is responsible for defining the product’s features and functions. Most importantly. the ScrumMaster is a facilitator. and three central artifacts or tools that Scrum teams use to organize and track their work. supervising the daily tasks of each contributor. either interim or final. we’ll look at the “ceremonies” and the artifacts that Scrum teams apply. and barriers is a key element of the ScrumMaster’s role. Development team The development team organizes itself and the required effort to deliver the results and collaborates both internally and with the product owner and his colleagues to determine the feature set. There are three key roles in a Scrum effort. conflicts. but the responsibilities and approach are quite different. the team and its members determine for themselves who will take responsibility for each feature or story and how they’ll tackle the development activities. a coach. for collaborating with the ScrumMaster and the development team to review each iteration and determine the product’s suitability. sheltering the team from barriers. the team decides for itself how to perform the work and deliver the results. This data-driven approach to product development is the foundational idea of Scrum and of all agile methods. The three central roles in a Scrum effort are: the ScrumMaster. The ScrumMaster spends his time as a facilitator. refine their course until they deliver what the customer wants. Product owner The second role is that of the product owner. the ScrumMaster must know the status of all the features that the team has uncovered in the requirements or story exercise and must maintain the Burndown chart to reflect the current state of development. ROI expectations. The ScrumMaster also must focus on any political. Let’s take a look at the roles first. 127 . owner is the ultimate authority in deciding if the work results. modify. the resolution of problems. ScrumMaster The ScrumMaster plays the role that a project manager would take in a traditional project. interference. market conditions. Unlike a traditional project. collaborating with the product owner to define the project goals and to enable the Scrum team to work toward those goals in the most productive way. or personal impediments that might derail or delay the effort. the designated product Three key roles in Scrum The number three plays a central role in Scrum. cultural. Scrum teams take the idea of “ownership” seriously. recording progress in project plan and Gantt chart. Stay tuned Next time. or as a project bureaucrat. and to perform the actual development of the work product. and a collaborator. to segment it into sprints. and for working with the team to adjust. Rather than behaving as a project foreman. and external politics and leading them through the Scrum practices and activities toward the successful delivery of the best result. Like the project manager in a traditional environment. and the development team. and reprioritize the feature set based on business needs. are acceptable.by that interaction. the product owner. the work is not parsed out into granular tasks for the team. and technical hurdles that arise. Whether the issue is a client participant who isn’t available as promised for collaboration or a team member whose skills are not as expected.
A key aspect of positive risk is that you put yourself in a position to take on the risks. Normally risk events have a negative impact on our project.Take positive risks to gain project benefits Risks are future events or conditions that have some probability of occurring and that will some impact on your project. in which case we might be worse off than when we started. 128 . Even without understanding the specific technology in question. However. The new technology is not understood as well. has more opportunity for problems and you don’t have nearly as solid of a support infrastructure in case something goes wrong. or our implementation of the technology. They’re not guaranteed. Generally when we’re doing risk management on projects. There is an impact to our project. Remember that all risks have a probability of occurring. of course. could turn out bad. Your team probably understands the current technology better. and they punish people that take risks and fail. Your risk plan should include activities designed to give you the best chance that the risk event will come true. This is still the case with positive risks. If you take an intelligent risk and you fail. The technology. There is a probability of the event occurring. but this is generally true. it makes sense that projects with new technology would be somewhat riskier that a similar project that uses current technology. In our prior example. why would you ever undertake a project with new technology? The answer. Different organizations have different tolerances for risk. However. Would it make sense to you if I said that your project was riskier than a similar project that is using current technology? On the surface this would seem to be correct. (I know there are exceptions. you can also identify the risk events that lead to positive outcomes. we could make the decision to move forward with 100% confidence. This still meets our definition of risk. But are all risks really bad? Let’s say your project was going to utilize a new tool or new technology. However. with positive risk there is a potential positive impact. then they are really risk averse. the current technology is probably more stable and you probably have a lot more support infrastructure. the potential impact to our project is a positive. what happens? If your organization rewards people who take risks and are successful. they are risks that we knowingly take upon ourselves because we perceive there to be advantages to doing so. we’re talking about potential negative events. the project manager or project team may introduce risk to try to gain much more value later. In other words. Positive risk is also called “opportunity risk.” In these instances. We usually think of risks as being bad and we try to put a plan in place to make sure the risk goes away.) So here’s the question: If it’s true that all projects are generally more risky when we use new technology. is that we perceive there to be a benefit to our project. if the benefits of moving to new technology were guaranteed. usually the benefits are not guaranteed.
The purpose of quality control is to inspect or test the deliverables to find as many remaining errors as possible. As you can see. Therefore. it would be much cheaper to find a problem with a computer chip when the chip is manufactured. If you see the problem during the requirements gathering process it might just take a call to your client and the quick update of a Word document to fix it. There was a project early in my career that applied poor shortcuts to the development process. if the error isn’t caught until after the chip is sold to the customer. if you discover this problem in the testing phase.to the detriment to the overall project. it actually took much longer to fix the problems later . Likewise. etc. they figured they would write the code and make sure it compiled cleanly. with the attitude that they could “fix it in the testing phase. Figure A errors. In fact. It will also require you to re-test the solution again. This greatly minimizes the impact of correcting the On many projects the team plans to find as many errors as possible during the testing process. But by pushing these errors further downstream. errors in the deliverable created in the Analysis Phase should be caught in the Analysis Phase.” They thought that they were just deferring their unit test time until later in the project. if you were manufacturing a computer chip. In Figure A. On the other hand. One important aspect of quality control is to find errors and defects as early in the project as possible. the solution design. it could impact the business requirements. it’s much better to spot problems with business requirements during the analysis phase of the project rather during the testing process. with some errors not caught until support/maintenance. 129 .Find errors as early as possible on your project Project teams generally use three types of quality management activities: Quality planning Quality control Quality assurance The purpose of quality assurance is to prevent as many errors as possible by having sound processes in place to begin with. we see a traditional approach to finding errors. It is much better to catch any errors that are introduced as quickly as possible. there will be a large payback as the project progresses. errors introduced in the Design Phase should be caught during the Design Phase. In Figure B we see the better approach. However. and some of the construct work. this is a potentially huge impact to your project. the cost to make the repair might cost more that the entire cost to manufacture the product to begin with. a good quality control process will end up taking more effort hours and cost upfront. For instance. rather than have to replace it when a customer brings the computer in for service after a purchase. Then they would then call the module complete. In other words. Since the programmers were under time pressure to complete their modules.
130 . rather Figure B than hope to catch and fix problems during the testing phase at the end of the project (or worse. have the client find the problem after the project has been completed).The bottom line is that the project team should try to maintain high quality and low defects during the deliverable creation processes.
you need to resist the urge to think that quality means the best material. No one likes to work on projects that are missing their deadlines because of rework. However. the hope is that no more work is needed. The purpose of quality management is to first understand the expectations of the client in terms of quality. if the client has a choice. if there are subsequent errors when your component is tied into the larger application. The two keys to avoiding lapsing into substandard quality management are to remember. In addition to poor morale in general. the client does not expect. However. the client will not be happy. This is work that Poor morale No one likes to work for an organization that has poor processes or produces poor quality solutions. For instance: Missed deadlines and budget In many cases. Here’s how to do just that. second. the team’s motivation level will go down when it has to continually repair and rework deliverables that don’t work correctly. Heed the signs Problems with quality show up in a number of areas. first. the client can still say that the project delivered to a high level of quality. On the other hand. it may not buy from you again at a later date. or it may change the value proposition for the entire project. Rework means that you have to do the same work twice because the original effort was not satisfactory. This can cause the business value to be delayed. that the project sponsor and your client determine quality—the project manager and project team do not. When you say the component is complete. a perfect solution. there is a cost associated with rework. Component walk-throughs or peer reviews are not considered rework. rework is required. many times quality problems surface after the project deliverables are completed and in production. For example. since they are part of building the component the first time. let’s say your team has created a software component in a large application. And. or else it did not realize the poor quality because the team’s testing process was also inadequate.Inadequate quality management will result in project problems Poor quality management can stand in the way of a successful project. However. If there are just a few bumps in the project. Some of this unhappiness may be transferred to the support organization. defect-free solution that does not meet the client’s needs will not be considered high quality. and cannot afford. projects that do not manage quality well end up with a lot of rework. However. Rework This is the primary problem caused by poor quality work during a project. which in turn leads them to miss their deadlines and exceed their budget. the best equipment. In most cases. a flawlessly designed. High support costs from a poor quality solution are a sign that the team willingly delivered a less-than-acceptable solution. and absolutely zero defects. This situation just hands the problem off to the support organization. Higher maintenance and support costs If errors are caught within the development process. specific costs can 131 . People tend to find excitement and challenge in building a solution. and then put a proactive plan and process in place to meet or exceed those expectations. Client dissatisfaction If a solution is of poor quality. is required because the original construction and testing process was not thorough enough and errors still existed in the deliverable.
and a smooth production cycle. checklists to ensure that all parts of a process were completed. Then you can work quickly toward final approvals. 2. Criteria for completeness and correctness I said earlier that quality is determined by the client. The second goal is to catch any errors as early as possible. your overall project will have much fewer problems. However.include increased absenteeism. Quality control process Quality control refers to the ongoing activities that the project team will perform to ensure that the deliverables are of high quality. Everyone on the team needs to have a quality mindset to 132 . The project team and client then have a common expectation of what is required for each deliverable to be accepted. the project manager should prepare an overall Quality Plan containing these three major components: 1. higher turnover. From a practical standpoint. Quality management is an ongoing process that the team needs to focus on throughout the project. testing should only confirm that everything is working correctly. ensure that work is completed with a minimum amount of errors—the first time around. Quality assurance process These are the activities designed to ensure that the overall processes used to create the deliverables are of high quality. not by the project manager. That is where completeness and correctness criteria come in. completeness checklists. This can include deliverable walkthroughs. testing of subcomponents. and less productivity from the staff. These types of activities include third-party audits. and so on. That might make the project manager uneasy. and deliverable approvals. implementation. What can be done? Quality management is not an event that you consider once in a while. if you have a good quality process in place. The project manager and team need to understand that the first goal of quality management is to produce deliverables with no errors. and then find those remaining errors as early as possible. Quality problems tend to show up late in the project—usually during the testing process. since he or she may not be sure of the client’s expectations. When the project begins. 3. if you can build the deliverables with as few errors as possible.
Microsoft Project 2007 4 .
and workload. but I find it more useful to create my own set of custom reports to answer specific key questions. click Copy and rename the Name field to Behind Schedule Report (Figure C). I want the report to list the Task ID. 3. 133 . Microsoft Project comes with a lot of reports categorized by activities. Task Name. costs. 1.) Change the Filter to the Behind Schedule filter and click OK (Figure C). Finish. Baseline Finish. In this report. Once I print the report. Click the Custom icon. When the Behind Schedule filter is complete. (Keep the Table: Entry since you copied it from the original Tasks report. I want to identify the late tasks and identify the responsible resource. Go to Report | Reports from the main menu (Figure A). however. You can access a lot of the information using Microsoft Project’s tables and views. 5. and Resource Name columns. This tutorial features the Behind Schedule filter that we created in a previous column to develop a Behind Schedule Report. assignments. you need to create the Behind Schedule filter in Microsoft Project 2007. Instead of creating a separate view. 2. Scroll down and click the Task report (Figure B). open the Report dialog box. Baseline Start. Here’s how to generate a custom report based on an existing filter. In the Task Report dialog box.Add a custom report in Microsoft Project 2007 Microsoft Project’s scheduling engine is full of data ranging from activity field definitions to earned value management calculations. A better option is to use Microsoft Project’s reporting features. printing this information can be tedious as you try to fit all the columns on one screen. I’ve used the delivered reports for summary level information. If you don’t see the Figure A Figure B Create a custom report based on an existing filter First. I’ll distribute it to my teams and include it in my status report packet. Start. 4.
you can quickly identify late tasks. and indicators. following the same copy report process. Baseline Finish. view. and the late tasks will display in a report format (Figure D). By developing different views and reports. In the report example. and reports. When sharing information with the immediate team or project stakeholders. go to Report | Custom.Behind Schedule filter in the drop-down list. I demonstrated how you can customize Microsoft Project to identify late tasks using filters. I recommend finding a report that contains the base data elements. Conclusion In my recent TechRepublic tutorials. and click the Preview button. Enter the status date. you can also print the report as a PDF and distribute it. The key takeaway from these articles is to use Microsoft Project’s default tables. Finish. By adding a few custom reports. You can choose any table or filter to meet your criteria. I find that using the custom reports approach is better than trying to print specific views from Microsoft Project. or tasks assigned to specific resources. go back and create it. I hid the % Complete and Duration columns because the information is supplemental. filters. and applying the appropriate filters. it can help you interpret the schedule data in your project schedule. Start. and Resource Names columns. Task Name. If you want more columns in the report. If you have a PDF driver like pdf995 installed. I added the ID. Remember that the Baseline Schedule filter requires a project baseline to be set in order for the filter to compare the status date to the original baseline. select the Behind Schedule Report. and filters to answer commonly asked questions when managing a project schedule. Run the report To run the report. Baseline Start. unstarted tasks. Figure C Figure D 134 . The report will prompt you for a status date. you need to add the specific columns into the Entry table. graphical indicators.
Select Tools | Customize | Fields.e. Select an unused Number field (i. Number2.) Once a project baseline is set and you record your weekly Figure A 135 . I hope this tutorial inspires you to do so. 2. To build the Late Indicator.. Here’s another approach to identifying late tasks: using a graphical indicator. the tool compares the project baseline against the weekly project status date. select the Number value. Enter this formula: IIf([% Complete]<>100. Click the Rename button.DateDiff(”d”.) project status date in Microsoft Project. (If you don’t use a Baseline Plan to manage your projects. In previous tutorials. 3. I showed how to build the Behind Schedule filter and how to use the Slipping Tasks filter. (This tutorial is specific to Microsoft Project 2007. the graphical indicator will quickly identify all the late tasks in your schedule as well as the tasks that are not behind schedule. 4. This is a useful way to review all the project tasks in one view and use a graphical indicator to show if a task is on or behind schedule. Number1. this graphical indicator will not work. 7.[Status Date])) The formula (Figure C) examines all incomplete tasks and Late Indicator The Late Indicator (Figure A) is based on a simple calculation that looks at all incomplete tasks and compares the Baseline Finish Date to the Project Status Date. In the Type combo box. Enter Late Indicator in the Rename Field (Figure B). 6. 5.Add the Late Indicator tool in Microsoft Project 2007 One challenge in reviewing project schedules on a weekly basis is quickly identifying late tasks. Note: If you don’t manage the project schedule using a Baseline Plan.[Baseline Finish]. Like the Behind Schedule filter. follow these steps 1. Click the Formula button. Number3).
Click OK. At this point. Figure B Figure C 136 . If a task is incomplete. The next step is to insert the Number field into your Gantt Chart view and set the Project Status date.compares the Baseline Finish Date to the Project Status Date field. values. Enter the following tests. a custom field has been modified with a formula that displays a graphical indicator. 11. the difference between the two dates will be reported. In the Values to Display section. click the Graphical Indicators radio button. I modified the Late Indicator Formula 8. and images from the drop-down boxes (Figure D). In my example. 10. Click OK twice. 9.
your status reporting by applying the Milestones filter. Summary Microsoft Project can present an overwhelming amount of data with its different views and underlying data tables. The last step is to update the project status date. Remember that you’ll need to update your project progress weekly and change the status date accordingly. the indicators will change. Figure D Figure E 137 . As the project progresses. I find it useful to include graphical indicators in a project schedule so anyone viewing it can quickly determine if there are tasks running behind schedule. the graphical indicator will “light up” and identify the late tasks with the red bulb indicator. It can also be used in 13.Number2 field and. the indicator will disappear as the indicator looks only at incomplete tasks. Go ahead and experiment with the different formulas and graphical indicators available in Microsoft Project. Select the Project Status date from the dropdown calendar. When a task is completed. In a future tutorial. I’ll share a few more useful formulas and graphical indicators that help improve status reporting. Once the Status Date is set. to add it to my current view. I selected Insert | Column and selected the Number2 (Late Indicator) field from the Field Name drop-down menu. 12 Select Project | Project Information (Figure E).
select the Slipping Tasks filter from the Filter combo box (Figure A). By examining tasks that haven’t started yet or tasks that are forecasting past their baseline start date. you will identify any work that is shifted to future dates. To clear the Slipping Tasks filter. The task is in progress and has an Actual Start of 4/20/2010 and a Forecasted Finish of 4/22/2010. The project manager needs to determine if the shift impacts the critical path and its impact to project milestones. The project manager needs to determine if the variance is acceptable or if additional action is required to realign these tasks with the original baseline start dates. then you’re already on your way to actively managing your plan.Slipping Tasks Figure B Slipping Tasks filter applied. If you’re examining behind schedule tasks. If you don’t watch for the shift in your project schedules.Identify slipping and unstarted tasks with Microsoft Project filters In a previous Microsoft Project tutorial. late starts. I showed how to identify late tasks using the custom Behind Schedule filter. that have been extended past the Baseline Finish date. Identifying late tasks is just one useful action that PMs should conduct weekly. Microsoft Project provides useful filters to identify slipping tasks and unstarted tasks. and slipped tasks. and all the tasks will be displayed. All of the Interface tasks haven’t started. This represents a shift of three days from the original project schedule. Another important schedule management activity is to examine any unstarted tasks. in the Formatting toolbar. 138 . To view the Slipping Tasks filter. Fortunately. but those tasks also inherit the three day shift from previously completed tasks and work in progress. The All Tasks filter Slipping Tasks filter The Slipping Tasks filter is a pre-built Microsoft Project filter that identifies all the tasks that haven’t started and have a forecasted finish date that is greater than the Baseline Finish date. the Use Case 1 task had a Baseline Start date of 4/15/2010 and a Baseline Finish date of 4/19/2010. This filter will identify the shift in your project schedule and list all the unfinished and future tasks Figure A Formatting toolbar . select the All Tasks filter. In the project schedule in Figure B. you risk missing deadlines.
Select the Unstarted Tasks filter from the Filter combo box in the Formatting toolbar. follow these steps: 1. you’ll have a good idea of the tasks that need action and follow up with the project team members. The result is a list of tasks that should have started by the project status date (Figure D). To identify all the tasks that haven’t started as of the project status date. Custom Baseline Start AutoFilter Figure D Tasks that should have started by the project status date 139 . 2. 3. Using the Auto Filter button. I’ve seen several project schedules where the project manager uses the schedule as a task list and only tracks percent complete. If the project manager doesn’t update the actual start date or provide an update to forecasted finish dates. I use this filter frequently so I can filter on the Baseline Start Date to identify all the tasks that should have started by the given project status date. Insert the Baseline Start column into your view.is useful only if the project manager has an established project baseline and actively tracks actual start and finish dates. the schedule will always match the baseline. this technically means the Actual Start date for each task is equal to NA. Unstarted Tasks filter The Microsoft Project pre-built Unstarted Task filter identifies all the tasks that have not started. Summary By tracking your unstarted tasks and behind schedule tasks. Then the real “fun” begins as you look to realign the slipped work to the original project baseline. I recommend you track your project schedule objectively. In this case. To avoid this situation. You should expect to see a few schedule slippages. the filter will be useless. create a Custom AutoFilter where the Baseline Start Date Is Less Than Or Equal To Your Project Status Date (Figure C). This includes all tasks in your schedule including future scheduled tasks. as the baselined project schedule is a point in time forecast and every task doesn’t execute perfectly according to the project schedule. Figure C The key takeaway is to look at the Baseline Start and Baseline Finish dates and compare those dates to the current Start and Finish dates and examine the variances.
4. I typically receive an Excel file with tasks and start and finish dates. Select the Microsoft Excel Workbook (*. When you import an Excel file into Microsoft Project. Figure A Microsoft Project Excel import without task hierarchy. The obvious solution is to have the vendor provide its Microsoft Project schedule. 2. follow these steps: 1. Open a sample Microsoft Project schedule.xls) as the Save as Type and click Save. 5. Click Next and leave Selected Data as the option. If you’ve worked with outsourcing vendors. Creating the hierarchy in Excel usually involves grouping and indenting in Excel or using a custom macro to build the hierarchy. I developed an import map that will properly import the Excel sheet that builds the task hierarchy in Microsoft Project. When you export data from Microsoft Project into Excel. 140 . Ironically. To build this map in Microsoft Project. 3. Click New Map. then you’re familiar with some vendors who don’t consistently use Microsoft Project as a scheduling tool. In my case.) Go to File | Save As.Importing a vendor’s Excel schedule into Microsoft Project For the past four years. the reality is some vendors are reluctant to hand over their detailed schedule because it contains cost data. custom macros. and other private data. One challenge in jointly delivering a project with an external vendor is obtaining the vendor project schedule in a format that can be integrated with Microsoft Project. (It helps if you have a completed project schedule so the final export will have meaningful data. it also lacks any of the indenting (Figure A) and summary tasks that make Microsoft Project a valuable roll-up tool. Building the import map My solution was to develop an import map that includes the key fields in Figure B. the data file doesn’t maintain the hierarchy. notes. I’ve worked for companies that outsource the majority of their IT work to external vendors using fixed-price contracts. Faced with the poor usability in scanning hundreds of tasks using Excel. my vendor extracts this information from his Microsoft Project schedule and provides an Excel file that I can scroll through to find key milestones and due dates.
In this case. 7. I had to build the export map for the vendor so they could simply export their Microsoft Project data into a format that I could use to import the file. Click the Finish button. their schedule could easily be imported into Microsoft Project by following Figure C these steps: Export Wizard . Click the Microsoft Office Project field and select the fields in Figure B. 10. 8. Once the vendor provided a file using this format. Click Save Map and Save It as Excel MPP Map. Click the Next button.6. 9. The Excel extract will now contain the key Figure B fields needed to build the project hierarchy. Once the vendor had this map in their Microsoft Project file. while the critical data that I needed to understand milestones and start and finish dates for key tasks could be imported into my Microsoft Project schedule. It ensured the vendor’s confidential data was kept confidential.Task Mapping 141 . the vendor could easily save an Excel file using this extract. Select the Tasks checkbox (Figure C).
Select Use Existing Map. Click the Next button. I ran into calculation issues because the % Complete field is a calculated field and didn’t consistently convert. 4. Applying these concepts to other schedules You can apply these same map concepts to other schedules that lack the Outline Level. Change the Files of Type combo box to Microsoft Excel (*. Before I came up with this solution. you may outsource the work to another supplier and establish penalties for failing to meet milestones. Select the Excel MPP map. 2. From a financial viewpoint. effective project managers collaborate with all their team members (vendors. Click the Next button. I insert them as subprojects in the master project schedule. it makes sense because a fixed-price contract puts all the risk on the vendor. Once the schedules are converted. Select the extract file and click Open. I would import the Figure D Import Wizard . In fixed-price outsourcing projects. In Microsoft Project. Start Microsoft Project with a blank project schedule. schedule as a new project. go to File | Open. customers. A key to being a successful PM is tracking to an integrated project schedule so the team can collectively understand progress. 7. 9. however. 5. 11. Click the Next button.xls).Import Mode 142 . you can easily identify late tasks and analyze the critical path. The main benefit is that once you have the vendor and your project activities defined in one integrated view. 3. Select Append the Data to the Active Project (Figure D). If the vendor can’t provide all their schedule data. 10. but you’ll need to build the Outline Level manually. this Excel MPP map will help integrate the data you need. 8. The end result is a properly formatted Microsoft Project file that contains the vendor’s project schedule. Depending on the level of granularity required. you might just want the vendor’s key tasks and milestones instead of the entire project schedule. 6.1. and internal team members) to deliver their projects. Click the Finish button.
I followed these steps: 1. Figure A Rethinking my first approach My original approach was to identify a late task by filtering on the % Complete field. Insert Baseline Start and Baseline Finish. date. Confirm the % Complete column is in the view. late. Filter on the Baseline Baseline Finish filter % Complete filter Figure B 143 . I had to remove the filter and then rebuild it a few minutes later. it’s valuable to be able to quickly identify late tasks without scrolling through a large hierarchy of tasks. or slipped tasks by using one of these options: This approach worked to generate a list of late tasks for Tracking Gantt view Incomplete Tasks filter Late Tasks Assigned to Resource filter Slipped/Late Progress filter These built-in filters are nice. Filter on the % Complete column (Figure A). once I switched views or needed additional information. The need for a quick and reusable filter to identify tasks that Finish date where the Baseline Finish Is Less Than Or Equal To a given status date (Figure B). Select the Tracking Gantt View using the Entry Table. 2. So I decided to create a custom filter in Microsoft Project that would identify late tasks. project status reviews. and the Resource name column. 4.Identify late tasks with this custom Microsoft Project filter When managing a project schedule of even a moderate size. 5. The resulting schedule identifies all the tasks that haven’t finished and can be filtered by resource (Figure C). 3. you can identify incomplete. but I usually need to filter on a different set of criteria to view the data I like to see. This process quickly became tiresome to simply view late tasks. In Microsoft Project. the Baseline Finish. however.
The text entered between the quotation marks is the actual text that will appear in the dialogue box. Click the second row and select the % Complete field. Creating the Behind Schedule filter You can create your own custom Behind Schedule filter by following these steps: 1. Figure C Late tasks using Auto Filter Figure D Behind Schedule filter 144 . Click the first row in the Field Name and select the Baseline Finish field. Enter “Status Date:”? into the Value field (Figure D). 5. 4. (It is important to enter the question mark after the quote value. Enter “is less than or equal to” as the test condition. Enter “Behind Schedule” in the Name field.) 6. 2. 3. as this represents a parameter. Select Project | Filter For| More Filters and click New.were behind schedule led me to create a custom filter that I named Behind Schedule.
The filter will identify any incomplete tasks based on a selected date (Figure F). Using the Behind Schedule filter To use the filter. click the Behind Schedule filter in the Formatting toolbar and select the Project Status date. 2: Look at Slipping Tasks.7. Three key points about using the filter 1: Remember to baseline. Select the “does not equal” Test condition and enter 100% as the value in the Value column. you should apply a rolling planning approach and baseline the tasks for the next phase or major milestone. In order for the filter to work. and all the project tasks will display. To clear the filter. Figure E Building a custom filter Figure F Late tasks using the Behind Schedule filter 145 . you need to baseline (gasp) the project schedule. click the All Tasks in the Filter combo box. If project teams are hesitant to baseline the entire schedule. The Behind Schedule filter identifies only tasks that are incomplete and have exceeded the 8. Click the OK button (Figure E).
I encourage you to also look at the Slipping Tasks and Slipped Tasks\Late Progress to identify tasks with impacted start dates.baseline finish date. and click the Copy button (Figure G).mpp file. Figure G Adding the Behind Schedule filter to Global. select Tools | Organizer | Filters. The Behind Schedule filter that you created is a local filter that is available only in the current . If you want this filter to be available for all your projects.mpt file.mpt file for future projects.mpt file. select the Behind Schedule filter.mpt 146 . To add a custom filter to your Global. you need to add the filter to your Global. Conclusion You can create additional filters based on your criteria by following the steps outlined in this tutorial. 3: Add the filter to your Global. which contains all the custom objects for your Microsoft Project files.
When PMs communicate dates. Although PMs try to forecast the future.Scheduling project uncertainty with LiquidPlanner Project managers spend a lot of time attempting to develop the perfect project schedule with bottom-up estimates.” How it works Instead of selecting a specific date to complete a task. This Web-based project scheduling and collaboration tool will likely change the way PMs think about project scheduling. they often use absolutes. The good news is that it’s not hard to manage uncertainty once you can visualize it. and unwelcome surprises. Instead of specifying a single point duration estimate. Consequently. as uncertainty occurs throughout project execution. you can’t manage what you can’t see. which is exactly what LiquidPlanner does. To put it simply. Figure A Then. The easiest way is to build that insight from the bottom up with ranged estimates and a realistic scheduling method. which don’t allow for fluctuation based on a best case or a worst case estimate. and I was pleased to learn about LiquidPlanner. you can enter a best case and Sample project schedule with ranged estimates a worst case 147 . LiquidPlanner uses a ranged estimate that allows you to specify a best case and a worst case duration estimate. late tasks. to discuss managing uncertainty in a project schedule. Despite all the upfront planning with welldefined single point estimates. This approach works as long as the amount of uncertainty doesn’t exceed the project buffers. According to Mr. Seybold. LiquidPlanner: A unique way to handle project scheduling I have been looking for an alternative to my current approach for scheduling uncertainty. they haven’t invented a project tool to predict the future. it makes sense that we should start planning and communicating our schedules by incorporating uncertainty. CEO of LiquidPlanner. projects still experience schedule slippage. A typical approach to scheduling uncertainty is to add time buffers at the task or phase level that expand the project duration and provide enough “cushion” for you to handle unknown project delays. “Unmanaged uncertainty is the silent killer of projects. I recently interviewed Charles Seybold. LiquidPlanner’s scheduling engine applies statistics to determine the probability of completing a task by a given date (Figure A).
However. the dates automatically adjusted and displayed the probabilistic completion dates for the entire project. don’t need to resource level the plan since Liquid Planner automatically performed the calculations. an expected finish. he writes about applying rolling planning and only committing to a milestone date a few weeks in advance. a given task’s duration will have a best case early start. and duration estimation. as resources and task start and finish dates automatically adjust based on the order of the tasks. In situations where the order doesn’t always imply a dependency. and I found it very easy to build tasks in a project schedule. LiquidPlanner’s implied dependencies were useful for developing a project schedule. Tool is consistent with expert advice In Neal Whitten’s book No-Nonsense Advice For Successful Projects. LiquidPlanner supports this approach by providing the PM a promise date and a range of probably completion dates instead of rigid dates that were established months ago without incorporating uncertainty. PMs will quickly see how useful ranged estimates can be in planning a project and communicating a project end date with a confidence range instead of an explicit date. As the team accomplishes the milestone. you can explicitly define predecessors with a few mouse clicks and create a chain of dependent tasks. if promise dates are passed. 148 . Based on the calculations. and the scheduling engine will calculate the duration ranges with task completion confidence levels. Another useful feature in LiquidPlanner is the dynamic resource management. the LiquidPlanner approach is a variant to the PMBOK standard of activity definition. as resources were assigned to tasks. sequencing. this feature is useful. LiquidPlanner assumed the subsequent task was dependent upon the predecessor. the system will automatically alert the project stakeholders. In Figure B. the duration date range will adjust and. In a waterfall project schedule.estimate. Also. resource allocation. Useful features I built a sample schedule using LiquidPlanner’s free 30 day trial. The ranged estimating approach also relieves some pressure from the project team to be 100% Figure B Task Duration Bar with probability ranges. as the date range provided a best case and a worst case completion date for the project. The project end date also didn’t unrealistically expand. a best case finish. He advises against committing to a launch date months in advance when priorities can change. the software forecasts a recommended promise date with a 98% confidence. As the project progresses. instead of adding explicit dependencies between tasks. and a worst case finish based on a probability calculation. You Benefits of ranged estimates For the traditional PM. then they commit to the next milestone date.
I’ll explore some of LiquidPlanner’s collaboration features that also help effective project delivery. In a future article. LiquidPlanner helps teams visualize uncertainty. and watch the company’s training videos. sign up for a free 30 day trial. 149 . Additional information I encourage you to visit the LiquidPlanner site. and PMs can do a better job of planning for it once they see the potential impacts.correct in their estimating and encourages the team to plan for change.
and respond to action items. For instance. In complex projects and programs with multiple vendors and business customers. they will need access to the tool to provide updates. you can achieve resource management. you should ask yourself the following five questions. the vendor may not even have network access to use the tool. For instance. but in large enterprise organizations. the entire resource pool needs to be converted from a corporate directory or an organizational hierarchy. I’ve found that there are multiple approaches and things to consider. Adding resources in PPM tools isn’t difficult. Do all team members agree to use the PPM tool? Project teams may comprise of business SMEs. a vendor will use their own PPM tool. record issues. this is easily accomplished. and objective project and portfolio metrics. After spending several years managing programs with these solutions. 1. In small organizations. Will all team members exist as resources in the tool? Organizations seeking to adopt resource management using project schedule data will need to create a resource entry in the PPM tool for every project team member. if these team members are assigned tasks on the project schedule. you quickly obtain a standardized view of the projects executing across the portfolio using real-time data. If your project uses external vendors. 2. Do all team members have network access and licenses to use the PPM tool? A PPM solution that is limited to the project manager falls short of the collaborative project benefits that a PPM scheduling tool provides. some project teams may prefer to publish a complete resource constrained project schedule.Considerations when integrating Microsoft Project and PPM solutions You can integrate and update a Microsoft Project schedule with a project portfolio management (PPM) tool such as CA Clarity or Microsoft Project Server. the issue repository. while providing input into the client’s project management reporting process. When I first heard about Microsoft Project integration with PPM solutions. Schedule detail I find it useful to determine the level of schedule detail required to support Microsoft Project and PPM integration. I thought it must be the fastest way to achieve transparency between the top-down scorecard hungry portfolio managers and the project teams performing the work. 4. All team members who need to update the project schedule. each camp of stakeholders will have their own processes and reporting expectations. Do all the project managers understand how to build a project schedule using a PPM tool? Microsoft Project and Clarity support resource management and maintain a resource pool at the server 150 . 3. In order to make that determination. The resource pool also needs to be refreshed and maintained as project teams turn over. Depending on your company’s budget. and the risk register will need network access and licenses to use the tool. schedule management. although it does require planning for a small conversion for larger organizations. time keeping. allocating licenses to every project team member assigned to the schedule could be a costly initiative. external vendors. Establishing how the different PPM tools will be used can help determine how to manage issues. and stakeholders outside of the core team. risks. When you incorporate standard reporting templates and integrated project schedule data. while others may prefer to incorporate a milestone only plan. and schedule management in a PPM tool. By doing so.
task baseline start and finish dates. although the decision making is only as good as the data in the system. then your project is better prepared to integrate the entire project 151 . You need to consider the application of the tool and its collaborative use within the project before jumping to a detailed or a milestone-level integration. and dependencies can be a significant. dates shift. If the project already has a developed project schedule. the effort to convert resources. and region-specific calendars. but they did appreciate the successful delivery of a project. Despite the one-click push button demonstrations. there are other techniques to consider in addition to examining project schedules. However. Tradeoffs Internal projects that use an established pool of resources and a single integrated plan can benefit from a complete project schedule level of integration. Is this a new project? Since PPM scheduling solutions require the project schedule to be developed with a central resource pool. Project managers need training to effectively use the server-based project schedule template. Evaluation If you answered “Yes” to all these questions. it will reduce the number of problems encountered when integrating project schedules within a PPM tool.level and will shift project end dates based on the resource pool’s commitments to other projects. corporatelevel holiday calendars. If the project managers are simply picking dates and assigning resources to tasks. The PPM features are enticing to use. A poorly developed project schedule wrapped within a PPM tool with all the whiz-bang collaboration features and dashboard reporting is still a poorly developed project schedule. I’ve created my own milestone-level project schedule that contains individual milestones from each project in the program. and it is a manageable but considerable undertaking. resource management may not be a priority compared to an accurate inventory of projects in the portfolio. schedule with the PPM solution. and develop the project schedule. I monitor these milestone dates by comparing them to the detailed level plans and update the PPM tool accordingly. the end result will be a constraint-based schedule that will cause frustration when resources are added. The project team will need to determine if supporting an administrative project schedule conversion is worth the time and effort for in-flight projects. In large programs. you will need to balance the administrative scheduling overhead in addition to the actual delivery of the project. task start and finish dates. and the project has been executing outside of the tool. Depending on the size of the project schedule. If you adopt this ap- 5. I favor a milestone-only approach. proach. I’ve converted in-flight projects into existing PPM tools. new projects are better suited to adopt the PPM solution. If you answered “No” to any of these questions. If the project managers understand how to build a dynamic project schedule by leveraging a calendar-driven resource pool. assign resources from the resource pool. If resource management is required. Integrating a milestone-only schedule will also require you to monitor milestone dates and update the data in the PPM tool separately. and overallocations occur. your project may be better suited to publishing a milestone-level schedule in the tool. If you decide to publish a milestone-only level schedule. No one ever rewarded me for publishing a detailed project schedule in a PPM tool. your organization will lose accurate visibility to the PPM resource management features and just-in-time schedule reporting. you should consider a conversion to the PPM solution. If your organization isn’t actively prioritizing resource management. integrating a project schedule with a PPM solution isn’t as easy as it seems.
and manage the project data (Figure A). task usage. and resource graph views. Figure A Figure B A look at myGantt view 152 . I’ve been using a custom view called myGantt that provides all the data I need to update project progress and track the project schedule (Figure B). (I’ve inherited project schedules that had more than 20 columns in a single Gantt chart view. Novice project managers remedy this problem by adding every column of data that they’ll ever need into the Gantt chart view. it can get confusing. You can create your own myGantt view by following these steps.Build a customized Gantt chart view in Microsoft Project The number of views into Microsoft Project’s scheduling data can be overwhelming. The delivered views on the Microsoft Project view bar include the Gantt chart. tracking. print. and it creates information overload. The end result is there are too many columns in one view. track. resource usage. core schedule data needed to define. and variance tables. cost. For the past few years. When you combine these views with the entry. and update your project schedule. It quickly becomes difficult to navigate.)One solution is to create a custom view that provides the This Gantt Chart view has too many columns.
Actual Start. enter myEntry for the Name. Go to View | More Views. Click the OK button. Repeat the steps above and use the myTracking view. Click Copy and rename the table to myEntry (Figure C). Create a custom myTracking table 1. 2. select the myEntry Table. Baseline Duration.Create a set of custom tables and views based on the delivered entry and tracking tables By creating custom tables and views. Figure C This is the myEntry table 153 . Go to View | More Views | New. you should include Actual Work and Baseline Work fields. effort-driven tasks. Baseline Start. Enter myGantt for the Name and select myEntry for the Top view and myTracking for the Bottom Views Displayed (Figure E). you’ll import the same data and still be able to switch back to the delivered Gantt chart and standard tables. Go to View | Tables | More Tables and select the Entry table. 3. 1. If you’re tracking Create a myGantt combination view The combination view splits the Microsoft Project workspace into two panels. 2. Remaining Duration. Repeat steps 1-3 from the previous section and use the Tracking table. (Figure D) Create a custom myTracking view 1. Actual Duration. Click the OK button. and set the Filter to All Tasks. Actual Finish. 2. Click the OK button. 1. 3. set the Group to No Group. Create a custom myEntry view 1. If you don’t create a separate set of tables and views. % Complete. In the View Definition dialog box. Baseline Finish. this allows you to see the entry and the tracking data all in one view. 2. Edit the table to include these fields: Name. any changes you make to the underlying tables will affect the standard views in Microsoft Project.
1. Primary benefit The key benefit of this myGantt view is the amount of time you’ll save switching between different views and inserting or hiding different columns. 1. views that you’d like to share with the community. By highlighting multiple tasks. you should see the myGantt view in your View Bar and in your View menu. Click the OK button. Go to Click On View | myGantt. you can easily revert to the original views by clicking the Gantt chart icon Figure D and removing the split view. Figure E myGantt View Definition dialog box. and the impact of those dates to the forecasted schedule. 154 . Since you created custom objects. view. 2. If you have developed innovative myGantt View Definition dialog box. The myGantt view from Figure B will be displayed. the actual dates. Since you created custom objects. Click the Show In Menu checkbox. the project manager is able to view the baseline dates. You can also change the upper and lower window panes based on the tracking or the resource utilization needs. I encourage you to discover new ways to view project data. you can record the actual duration and the remaining duration to generate an objective percent complete. please detail them in the discussion. you’ll receive all the key information you need to track your schedule. you can click on one task in the upper window pane and view all the relevant tracking data in the lower pane. you can easily revert to the original views by clicking the Gantt chart icon and removing the split view. Innovate Now that you understand how to customize Microsoft Project. You can change the upper and lower window panes based on the tracking or the resource utilization needs. Using this single combination Test your view By clicking the Show In Menu checkbox. With one combination view. The supporting Gantt chart can still be formatted to view the critical path or other Gantt chart wizard graph charts. With this view.
Import MS-Project Schedule into MatchWare MindView 3 Business. following the simple steps I outline below. and (my personal favorite) a timeline view. Unfortunately. but for practical status reporting. The Gantt chart is a great tool for project managers. The software will import your project schedule and build a Gantt chart view (Figure B). an outline view. filtered in the Gantt chart view. Using MindView 3 Business MatchWare’s MindView 3 Business simplifies milestone chart reporting. Using desktop office software requires manual changes every time a milestone is completed or a baseline milestone date changes — there is no clean integration with the project schedule and the reporting mechanism. schedule development. Fortunately. including a mind map view. a Gantt chart view. It also provides multiple views of project data. The problem is Microsoft Project doesn’t provide a user friendly milestone chart that users can easily understand. Open MindView and select Import | Microsoft Project. Project managers typically resort to Microsoft Excel or Microsoft PowerPoint to develop the appropriate milestone chart for status reporting (Figure A). I’ve found a tool that makes this administration task a breeze. The tool’s mind mapping and project management integration with MindView 3 Business is excellent. I’ve been using the software for several months and generating a milestone level status report takes less than a minute by Figure A Program work stream view. I detest creating and updating milestone charts. it can become unwieldy to manage. Figure B Filter on Milestones MindView 3 Business has a powerful filtering feature that hides project data based on your filtered criteria. The software is an asset to project managers implementing scope definition. as milestones and summary tasks can yield too many levels. activity definition. the 155 . and on-going status reporting. A unique feature in MindView 3 Business is the filtered tasks remain Gantt chart view of a sample project schedule.Build milestone charts faster with MindView 3 Business software A well-defined milestone chart is a useful way to communicate a project’s progress and to identify upcoming deliverables.
including activity definition and status tracking. Figure C Figure D Timeline view Filter dialog box Figure E Design and timeline layout 156 . Click the OK button. The final result (Figure G) is ready to export into an image file to be embedded in a status report. select View | Show Branch Data (Figure F) Select Start/End date and select either Priority. and formatting the objects in a Microsoft SharePoint file. click on the Timeline view (Figure D). For this example. You’ll be pleased to find changing the format is much faster than wasting time moving lines. Completion. or an email. To select the type of project data you want to display on the milestone chart. In the View ribbon bar. diamonds. or Resources. Click the Design tab and select one of the timeline layouts (Figure E). The Gantt chart view will now only display the milestone level tasks. a presentation.timeline view. click Add Level and select Duration Equal To 0 day. I only want to view the milestone data. and the traditional milestone view. This filtering is useful in a variety of project management applications. the outline view. The Design view provides a variety of timeline layouts that support multiple formatting options with a click of a button. When the Filter dialog box appears (Figure C). so follow these steps: Select Filter | New.
If you’re interested in taking MatchWare’s MindView 3 Business for a test drive. Until the project management gurus create an “Easy Button” for project delivery. you can download a free trial from the company’s site.Try this timesaver for yourself Using the Microsoft Office tools. As project managers. I’m just glad I found a tool that leverages the project artifacts I use on a daily basis. The MindView 3 Business method takes under 60 seconds and leverages the existing project data that I keep up to date in my project schedule. we accept the administrative burden as part of the job. I’ll continue to share the best tools for practical project management. but we should always be looking for faster development tools to make our job easier. Figure F Show Branch Data Figure G Milestone view in under 60 seconds 157 . I can easily spend one or two hours creating the chart and spend even more time tweaking each milestone so it aligns with the graphical timeline.
and forms (or screens) and assigning a complexity level of Figure A MyEstimation table 158 . assign a complexity rating. Over the past few years. Interface 1 had a baseline duration of 2 days. and high estimates were assigned 32 to 80 hours of effort. I can start building better estimation metrics. project teams conduct either a bottom-up or a top-down estimate. conversion. or high. Agile enthusiasts acknowledge project teams should conduct retrospectives (a. I can refine my estimates using both units. this activity usually occurs at the end of the project.k. a common practice is to highlight what went well and identify areas for improvement on a project. I added custom fields to categorize the deliverables. It helps to understand the root cause Effort estimation Project teams often spend time at the end of a project documenting lessons learned. lessons learned sessions) after every release and iteration. you can achieve an analogous estimation tool that is based on bottom-up data from past projects. Figure A depicts a custom table that I used to track and categorize the actual project data for future comparison. I can quickly see where I underestimated the code phases of specific interfaces. By examining the actual task data. I recommend comparing actual duration and actual effort to the baselined effort as part of a lessons learned session. Figure B includes a close-up view of the interface analysis. Regardless of your preferred methodology. The range was tweaked based on the information available. I started collecting metrics against the Microsoft Project schedule so I could develop a better estimate matrix based on actual project data. Since the data is recorded in days or hours. medium estimates were assigned 16 to 24 hours of effort. medium. enhancements. although few measure their actual performance and record it for future estimation. If you start collecting actual performance data and compare actual results against baseline estimates. and include a flag to include in my estimation analysis.a. Estimation matrix In my system implementations. and it took 6 days to complete the work. During effort estimation. interfaces. In this section. Low estimates were assigned 8 hours of effort. In waterfall projects. The key benefit was it provided a starting point for estimation based on basic information. Top-down approaches use analogous estimates and rely on expert opinion to estimate duration at a high level. a common practice involved developing an estimation matrix that categorized reports.How to use project data to develop a better estimation matrix During lessons learned sessions. Bottom-up estimates require a significant investment in time to define scope and build an accurate estimate. In this table. low.
of why a medium interface moved from 2 days to 6 days. In my next column. I am not suggesting you track every task. you continue to build a better estimation matrix. Based on the root cause. I can update my matrix in Figure C. After I export the data to Excel. I may adjust the matrix to accommodate better estimation. For your next project. deliverables. although I do recommend tracking against the major activities required to produce specific IT Figure B Interface actual and estimate comparison Figure C Estimation matrix 159 . I’ll show how to track and export this data using a variety of views and maps in Microsoft Project. you’ll need to conduct similar effort estimation activities. How do you track your estimates and build more objective estimation tools? Let me know in the forums. By comparing estimates against actuals for specific deliverables. Summary For a lessons learned session.
and maps. enhancements. If you follow the eight steps outlined below. you’ll need to customize the fields using the Tools | Customize feature in Microsoft Project. After you download the sample schedule. Text30. where you can use it for other project schedules. Click the Maps tab and copy the myEstimates map into the Global. Click the Gantt Chart view and switch to the myEstimateComparison Figure A 160 . 3. forms. Text29. and Include Estimation fields to the Global. click myEstimateComparison table. mpp file. as the effort estimation is based on prior experience for similar types of work.mpt file. This will copy this custom table to your PC. however. table. Select Tools | Organizer.mpt file. Task Complexity. and click the Copy button. I provided a very simple estimation matrix based on the common RICEF deliverables of reports. Task Category. Even Agile enthusiasts would value this approach for their next round of Planning Poker. you’ll be crunching numbers in a few minutes. and Flag20. These fields map to Text28. Step 1: Configure your estimation table I could write several articles on how to effectively customize Microsoft Project with your own tables. 5. view. The key benefit of tracking the actual project effort and comparing it to your original project estimates is that you can refine your estimation matrix for future analogous top-down estimation. 4. Click the Fields table and follow the same steps to copy the Estimation Category. and export map are copied to your local PC. I explained how to use project data to develop a better estimation matrix. it’s easier if you download this sample Microsoft Project file (Sample Schedule with myEstimates. If your project schedule currently uses these fields for other purposes. follow these steps: Step 2: Assign Task Category to tasks Once the project fields. 1.Export project data for future effort estimation In my previous column. You can tweak this matrix even further by analyzing the project data from your Microsoft Project schedule. interfaces. open your project schedule. conversion. and screens in Figure A. 2.mpp) and copy the relevant objects into your Global. Open the Sample Schedule with myEstimates.mpt file. Click the Tables tab. respectively.
Follow these steps to switch tables: 1.table. Step 5: Set the Include Estimation flag The Include Estimation field is used as a filter so you can view all the key tasks or deliverables you want to track in Microsoft Project or in a spreadsheet. The default Task Categories field includes these values: Report. Select View | Table. Depending on your estimation approach. Code. If you want to modify these values. table similar to Figure B with blank values. you may want to add values for smaller or larger work. you can modify these values to accommodate your systems’ development lifecycle. The custom table was created to replicate key Microsoft Project fields without modifying the core Microsoft Project table structure. Step 4: Assign Task Complexity The Task Complexity field consists of low. Test. You need to set the Include Estimation flag to Yes or No. 2. Figure B Figure C The Estimation Category field is used to identify the time spent in specific phases for key deliverables. You should see a Step 3: Assign Estimation Category The Estimation Category field includes Requirements. click the More Tables button and select the table. and Screen. Conversion. and high values. Find the key task you want to track in your project schedule and assign a task category from the drop-down menu. 161 . Select the myEstimateComparison table. Enhancements. medium. and Deploy valid values. If the table doesn’t appear in the menu items. Interface. simply click Tools | Customize | Fields and modify the Custom Attributes (Figure C). Form.
Click Next. Figure D 162 . 7. Programmers will be tempted to write macros to update the estimation spreadsheets. Click Finish. timation matrix only takes a little bit of data manipulation. you can save the file as an Excel export with just a few clicks. When the Export wizard dialogue box appears. Select Excel Work Book (*.xls). 6.Step 6: Repeat for each of the RICEF Step 8: Export to Excel using the myEstimates map deliverables you want to track for future estimation. 3. although I recommend project managers inspect the duration and effort data and make decisions on where to adjust their estimation matrix. Since you already have the myEstimates map. Select File | Save As. 4. enter a filename. The myEstimates map translation from the raw Microsoft Project data to your esExporting data from Microsoft Project to Excel or a different format is easy to do. and you can filter by Step 7: Export to Excel using the the estimation columns to further analyze durations. 5. click Next. 2. and click Save. Click the myEstimates Map (Figure D). Select the Use Existing Map radio button. Open the exported data in Excel. 1.
I use the same Microsoft Project file from last week’s column. Let’s get started. (See Figure A) 4. 2. When the Gantt Chart Wizard starts. Go to Select Format | Gantt Chart Wizard. To see the Gantt Chart View. 3. I explained the purpose of the critical path and why project managers need to be concerned about monitoring the project’s critical path during schedule execution. (I prefer to keep the default Resources and Dates options. Click the Format It button and exit the wizard. Open your project schedule in Microsoft Project. Keep the default links between the dependent tasks option and click Next. follow these steps: 1. you can download it from my article on Network Sensitivity and the Critical Path. follow these steps: 1. Choose the task information options and click Next.) 5. If you need to download the file. click Next. This tutorial has step-by-step instructions on how to view the critical path in Microsoft Project and interpret the data. Select the Critical Path radio button (Figure B) and click Next. Go to View | Gantt Chart View.View the critical path in Microsoft Project In my previous column. To start the Gantt Chart Wizard. 3. Go to View | Table | Entry. Figure A Sample project schedule Figure B Gantt Chart Wizard dialog box Figure C Critical path Gantt Chart 163 . 2. 6. You can also right-click the Gantt Chart and select the Gantt Chart Wizard from the pop-up menu.
Go to View | Table | Schedule. The critical and non-critical tasks will be conveniently grouped for further analysis and reporting (Figure E). I often use this view to determine which tasks and resources are on the critical path. so it has several days of float in the schedule before it impacts the project schedule. Click the Group By drop-down box (Figure E) and select Critical from the list of Values. It should be there by default. you can use the Group By option in the Microsoft Project toolbar.Figure C displays the formatted Gantt chart. With the formatted Gantt Chart. If you want to get a list of just the critical path tasks (Figure D). If any of these tasks are delayed. you can quickly view the available slack in the non-critical tasks. Confirm the Standard toolbar is displayed. you can go to View | Toolbars | Standard. Figure D Critical path tasks Figure E Group By option Figure F Schedule table 164 . then the project’s end date will be impacted. To view the critical path tasks. To view the slack in the project schedule. you can easily see the critical path and the project dependencies. but if it isn’t. follow these steps: 1. This extra level of detail helps me understand what needs to be accomplished and who is responsible for the task. The Schedule table is useful when you want to understand the slack in the schedule. Task 4 is not on the critical path. follow these steps: 1. With the critical tasks grouped. 2.
Figure G displays the Network Diagram. please view my How to View the Critical Path in Microsoft Project video. I’ll cover this more advanced topic in a future tutorial.2. Figure G Network Diagram 165 . The Network Diagram is another view that is helpful in understanding the critical path. To view the Network Diagram. The tasks highlighted in red display the critical path. which is located on the left hand side of the screen. while the blue tasks are not on the critical path. Microsoft Project can also create the standard forward pass and backward pass views with early starts and late finish data that you likely calculated if you prepared for your PMP exam. A Network Diagram is the classic Activity on Node schedule dependency diagram you may have seen in project management courses or in the Project Management Body of Knowledge. The Schedule table will be grouped by Critical and Non-Critical tasks (Figure F). You can also click the Network Diagram in your View Bar. If you’d like to see a video tutorial of these steps in action. go to View | Network Diagram.
and Microsoft Project calculates the third. Figure A: three-day duration with four hours of work In the Task B example. Insert the Type and Work fields into the Gantt Chart view. entered with a resource assigned 100%. For Three-day duration with four hours of work 2. 7. Using the Duration X Units = Work formula. and resource utilization. Since the project is outsourced to a vendor. a Fixed Work task could be Figure A 166 . Just like the scope. For internal projects with internal resource costs. and the three day duration will remain constant. He had a few challenges trying to schedule the task in Microsoft Project until we discussed the importance of task types and the Duration X Units = Work equation. 6. the others adjust as well. the project manager would care about the number of hours spent from a budget perspective. the fixed duration task is recommended. 4. the number of hours and resources can fluctuate.5 days. You get to choose two of these variables. Project managers run into a scheduling circle when they try to hold all three of these variables fixed. Since the requirement is to complete the task within three days. cost. units (or resources). To create a four-hour task using a three day fixed duration. work. In my colleague’s scenario. four hours of work. From a schedule perspective. the project manager is still expecting a three day fixed duration for the task. The project manager doesn’t care when the work gets done. 3. Microsoft Project schedules tasks based on three variables: duration. 5. Figure A depicts Task A using a three-day duration. the project manager has three days to complete four hours of work. My colleague was managing an outsourced project under a time and materials contract and wanted to schedule a four-hour task over three days. the project manager will enter duration and work into Microsoft Project and let the tool calculate resources. and the resulting duration would be 0. and the project manager doesn’t have direct control of the resource. Microsoft Project will calculate the 17% utilization. and 17% resource utilization. and time project triangle. Enter the task name. In actual practice using a time and materials contract. Enter 4 hrs in the Work column. I prefer to build fixed duration tasks using 100% allocated resources and let Microsoft Project calculate the work. a fixed duration task type is recommended. Assign a resource. as long as it’s in the three day estimate. and work. Enter 3 days in the Duration column. Change the Type field to Fixed Duration.Using a fixed duration task type in Microsoft Project A colleague and I were discussing how Microsoft Project calculates duration. follow these steps: 1. if you change one variable. By setting the task to use a fixed duration task type.
To learn more about the different task types. Use Fixed Duration. read my Microsoft Project tutorial. 167 .external projects that use different contract types. the mix of task types will depend upon the work and the level of tracking required in your project schedule. Fixed Work and Fixed Unit Type Fields.
5. Confirm the project status date is set in Microsoft Project before examining EVM metrics If you don’t specify the project status date. Confirm all tasks have resources assigned at the lowest level in the WBS A task establishes its baseline budget and planned value (PV) based on the resource costs 8. If you don’t have a defined cost for each resource. there are 40 critical success factors to successfully implement EVM in an organization. If teams use inconsistent practices.” If you’re unfamiliar with EVM.000. A properly developed Microsoft Project Schedule is critical in calculating EVM metrics when using Microsoft Project. the cost will roll up appropriately. EVM metrics are easy to calculate. it is important that anyone updating the project schedule follows a consistent procedure to record start dates and actual costs. EVM is an “objective method to measure project performance in terms of scope. Confirm no resources are over allocated Despite our desire to give 110%. time and cost. According to PMI’s Project Management Body of Knowledge. Confirm the work resources have the appropriate hourly rates in the Resource Sheet view Microsoft Project determines the work package’s budget based on each assigned work resource’s hourly rate. earned value can’t help you. Microsoft Project will assume the current date is the date used for calculating the earned value metrics.000. your earned value results may be off. One of those critical success factors is the project management team can develop a project schedule and track against a project baseline. a realistic schedule has resources only allocated 100% of the time. 3. According to industry research. you can’t measure what you’re trying to manage. 7. finish. Confirm the project management staff understands the procedures to record actual start. If you’ve built a poorly defined WBS. Confirm the project has a project baseline The project baseline establishes the time-phased budget for the project and allows PV to be calculated. duration. 1. and costs data for the project schedule As the project progresses.Confirm your Microsoft Project Schedule is ready for EVM Over the past nine years. your budget will be zero. The following is a quick checklist to confirm your Microsoft Project Schedule is ready for EVM. as it only requires simple math. 6. If your project contracted for $100. I’ve been studying earned value management (EVM) and its application to IT projects. assigned to the task. Confirm the Work Breakdown Structure (WBS) has been correctly defined with the appropriate work packages Meaningful earned value metrics are only as relevant as the tasks they represent. Since status reporting usually follows 168 . 2. read my overview before proceeding with EVM metrics in Microsoft Project. By ensuring resources are assigned to the lowest level in each work package. 4. the total cost in the WBS should reflect $100. Confirm the total costs for each work package match contractual agreements Microsoft Project builds a time-phased budget for each task and allocates planned work and costs according to the project calendar. If you don’t baseline the project. A poorly defined Project Schedule will result in poor EVM metrics.
How to Calculate EVA in Microsoft Project. you’ll want to set the project status date each week to calculate accurate metrics.the prior week. For more information about how to use earned value with Microsoft Project. Cnet Networks. 235 Second Street San Francisco. 169 . Copyright ©2009 CNET Networks. TechRepublic is a registered trademark of CNET Networks. CA 94105 U. There are 39 other critical success factors that organizations should consider before implementing EVM across an organization. Inc.A. Inc.. All rights reserved. Inc.S. read my tutorial. a CBS Company.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.