What is the key for successful project management? Do you follow a certain methodology? Do you use a certain software tools like MS Project for Gantt charts?

 Studies have shown that by utilizing software tools when managing projects, practitioners experienced better success in completing projects on time and within budget, while effectively fulfilling the project’s requirements. Project Management software allows project managers to design schedules, generate estimates, make scope decisions, and manage the development team for a successful outcome. Utilizing a software tool, managers can address each cornerstone of effective project management—planning, organizing, implementing, and measuring. These tools can also highlight conditions requiring executive action and decision making. 

There are many Project Management software available on the market. Some are heavily geared toward a certain industry and some are only able to do various Gantt Charts and depict the flow of the project. What really needs to be considered is the depth of which you need to track your resources and costs associated with the project.  Prospective customers of PM tool should examine all the functional capabilities (including integration support to third-party products), and identify initial functionality meeting immediate needs. An appropriate PM tool for a given company should match some immediate functional needs but also support the broader road map with more-advanced functionality and system options. 

Small to midsize companies that have a limited budget, a need for a fast PM deployment and has smaller IT departments can take advantage of Software-as-a-service (SaaS) based system. Choosing a SaaS based PM system allows the prospect to minimize the risk of a PM system implementation because PM application services can be limited to a month-to-month financial commitment with a PM vendor, as opposed to exponentially higher costs driven by licensing fees, consulting services and yearly maintenance contracts.

One of the SaaS based system is ProjectMgr.net, top-rated, multi-language project management software, that enables you to create, track, and maintain your projects online, which is easily accessible from any computer and optionally integrates to MS Project. It is an extremely easy-to-use and intuitive project management tool packed full of features that will undoubtedly save you time and money. ProjectMgr.net has been built with the understanding of how project management is executed in small and midsize businesses. 

ProjectMgr.net is a SERVICE, not a product. This means that you have all of the benefits of ownership without the burdens of high cost and constant maintenance. With the ProjectMgr.net service you don’t pay for product enhancements, support calls or re-training of staff, nor do you have the need to hire a “tech-guy” to integrate or oversee anything. The vendor takes care of version upgrades, server maintenance, latest virus threats, etc. which allows you to spend your precious time for project management.

• The Art of Project Management by Scott Berkun
• Agile Project Management by Jim Highsmith
• Head First PMP by Jennifer Greene and Andrew Stellman
• Strategic Project Management: Practical Tools for Leaders and Teams by Terry Schmidt
• Troubled IT Projects by John Smith
• Simultaneous Management: Managing Projects in a Dynamic Environment by Alexander Laufer
• Winning at Project Management: What Works, What Fails and Why by Robert Gilbreath
• Critical Chain by Eliyahu M Goldratt
• Head First PMP by Jennifer Greene and Andrew Stellman
• Project Management: A Systems Approach to Planning, Scheduling and Controlling by Harold Kerzner
• Project Management: A Managerial Approach by Jack R Meredith and Samuel J Mantel Jr
• Prince2 for Dummies by Nick Graham
• Project Management Demystified: Today’s tools and techniques by Geoff Reiss
• The Project Manager, Mastering the Art of Delivery by Richard Newton
• Project Management Communications Bible by William Dow and Bruce Taylor
• Critical Chain Project Management by Lawrence P Leach
• Alpha Project Managers: What the Top 2% Know That Everyone Else Does Not by Andy Crowe
• Just Enough Project Management: The Indispensable Four-step Process for • Managing Any Project, Better, Faster, Cheaper by Curtis Cook
• Project Management Methodologies by Jason Charvat
• Project Management Handbook by David I Cleland and William R King
• Successful Project Management: A Step-by-Step Approach with Practical Examples by Milton D Rosenau and Gregory D Githens
• The Fast Forward MBA in Project Management by Eric Verzuh
• The Billion Dollar Solution by Robert Newbold
• Mastering Project Management by Cathy Lake
• Perfect Projects by Eddie Obeng
• Project Management: The Managerial Process by Clifford F Gray and Erik W Larson
• MBA Fundamentals: Project Management by Vijay Kanabar and Roger D H Warburton
• 90 Days To Success As a Project Manager by Paul Sanghera
• Facilitating the Project Lifecycle by Janet A Means and Tammy Adams
Simply Brilliant: The Competitive Advantage of Common Sense by Fergus O’Connell
• The Mythical Man-Month: Essays on Software Engineering by Frederick P Brooks
• One Project too Many by Geoff Reiss
• Benefits Management by Gerald Bradley
• Herding Chickens by Dan Bradbury

Happy reading!!

A switch to agile often conflicts with personal goals such as maintaining the status quo, avoiding career risk, working no harder than necessary, or maintaining a large fiefdom of direct reports. It is to these individuals—those who have to become agile but don’t want to—that we would like to direct our advice. Don’t
worry. We’re not going to try to seduce you into trying agile, convince you of its merits, or tell you how to succeed. No, we’re going to help you fail with agile. Then you’ll be done with it and can go back to your comfort zone. Although there are many ways to sabotage your agile project, for convenience we have grouped them into four categories: management issues, team issues, product owner issues, and process issues. In each instance, we will cite an example of someone who successfully caused an agile adoption to fail, list the general guidelines for failure that the example is meant to demonstrate, and then list alternative techniques you can try to help you replicate the process. We hope this approach will allow you to fail quickly and avoid potential success.

Management Issues
Drew had seen management fads come and go. In his mind, agile was no different. A quick learner, he read a number of books and even took a class on agile. He didn’t trust it, but, as a team player, it was his obligation to give it a try. Drew picked team members and told them to “be agile.” He told them that they would need to meet daily, estimate their work, and produce versions of their product (a database tool for storing artwork) every month. Since Drew didn’t trust agile or his team’s ability, he attended every daily scrum, paying close attention and pointing out what the team was doing right and what it was doing wrong. Soon the daily meetings became a model of brevity and procedural correctness. As a bonus, no one spoke up about problems— especially in front of Drew. Drew had successfully followed our first guideline to agile failure.

GUIDELINE 1: Don’t trust the team or agile. Micromanage both your team members and the process.

To no one’s surprise, the team did not produce impressive results. It didn’t meet all of its iteration goals and was no more productive than it had been before. Drew conducted retrospectives that did not reveal any problems that he could fix. As a result, Drew threw away all the books he had read and directed the team to return to the old way of developing the project. Drew was following guideline 2.

GUIDELINE 2: If agile isn’t a silver bullet,blame agile.

While Drew went to one extreme by micromanaging his team, it is equally effective to go to the opposite extreme and not provide any guidance at all. Remember: While self-organizing agile teams are also self-managing, they are not self-leading. An agile team needs the type of leadership that provides a
vision to work toward and motivation for achieving that vision. A strong agile leader, often in the form of a product owner, knows how to motivate a team with a description of an extremely desirable product that is just beyond what the team may think it can do. Freed to pursue that goal and provided with ongoing guidance from a product owner, an agile team can become truly high performing. Don’t give your team that opportunity! If micromanagement isn’t your style, follow guideline 3.

GUIDELINE 3: Equate self-managing with self-leading and provide no direction to the team whatsoever.

While support for using agile may come from the highest levels of a company, often the adoption of agile will be driven by the team itself. Don’t worry. You still have plenty of opportunities to create failure in those cases, especially if you are the manager. You may want to start by undermining the evangelist on the team—the one who has read all the books and is taking the chance to promote agile. Brush off the rules he is asking you to follow. Interrupt the daily scrum with new directions. Change the priority of the iteration goals. It works well and is encapsulated in guideline 4.

GUIDELINE 4: Ignore the agile practices. They don’t apply to management.

If you want to be sure that agile doesn’t take root, go straight to the team members themselves and let them know you think agile is a fad. Some of them will be skeptical to begin with, so it won’t take much to convince them to ignore the practices. Remember, like Barney Fife, you have the power to nip this thing in the bud. Just follow guideline 5.

GUIDELINE 5: Undermine the team’s belief in agile.

Team Issues
Not all of us are managers. Don’t worry, non-managers can wreak havoc at the team level, as well. Just take the case of the NotQuite team, tasked with developing inventory-management software.This team shows the power of consistency in bringing down an agile project. For its first iteration, NotQuite committed to completing six items from the product backlog; it finished four. Because it was the first iteration and most teams overcommit in their first iteration, the product owner cut the team a little slack. This didn’t faze the NotQuite team. For the second iteration the team again planned to finish six items; it finished five. The slight improvement only lulled the product owner into a false sense of security. NotQuite continued to chronically overcommit, falling short in the third, fourth, and fifth iterations. Soon, the product owner learned not to trust the team, and this undermined any success it may have had with agile—a
fantastic implementation of guideline 6.

GUIDELINE 6: Continually fail to deliver what you committed to deliver during iteration planning.

When falling short, don’t make the mistake of going all-out on every iteration,reaching the last day panting with exhaustion time after time. A team like that could almost be forgiven for never quite delivering what it planned. A key to NotQuite’s failure was its cavalier attitude toward missed commitments. Team members made it clear that it really didn’t matter if something was finished on the last day of the iteration (as had been committed) or a few days into the next iteration. What’s a few days between friends? Remember, a few days here and there can add up to quite a lot. If a team continually misses its commitments, it makes it impossible for the product owner to make plans and external commitments. This leads to guideline 7 for how to fail at agile.

GUIDELINE 7: Cavalierly move work forward from one iteration to the next. It’s good to keep the product owner guessing about what will be delivered.

Perhaps the best way to cause an agile project to fail is to follow guideline 8.

GUIDELINE 8: Do not create cross-functional teams. Put all the testers on one team, all the programmers on another, and so on.

Merrilynn was able to use this guideline to kill her company’s pilot agile project. Her organization was developing an application that would have separate Windows and Web-based clients. As a development director, Merrilynn had control over team composition and was able to create three separate teams: a Windows team, a Web team, and a test team. This team structure worked against the goals of agile. If Merrilynn had wanted to succeed, she would have instead created three teams that each included Windows, Web, and test skills. Because Merrilynn kept the teams separate, she made it impossible for any
team to deliver the working software that an agile team is expected to deliver at the end of each iteration. Nicely done, Merrilynn.

Another option open to Merrilynn was putting all twenty of her people on one team. This would have violated the standard agile advice of creating teams of five to nine people. She could have justified it to anyone who questioned the decision by stressing the unique two client nature of her team’s product. If she had chosen to create one large team instead of three reasonably sized teams, Merrilynn would have substantially increased the communication overhead of her team. This would have slowed progress and created complaints about how all the conversations in agile were a tremendous burden. If separating teams is too hard to justify, you can bog down a project very easily by following guideline 9.

GUIDELINE 9: Large projects need large teams. Ignore studies that show productivity decreases with large teams due to increased communication overhead. Since everyone needs to know everything, invite all fifty people to the daily standup.

Product Owner Issues
If the management and team guidelines aren’t available to you, there is another route to take: Consider a takedown from the product owner angle. A product owner has many options at her disposal to bring an agile project to its knees. Take Kathy, for example, who was the product owner for a team working on a video game. The team was making great progress on features with every iteration and showing more player “fun” every time. Kathy let team members keep thinking that this was all they needed to do. She never attended reviews, rarely tried the game, and requested stories that were meant to steer the game toward the product she imagined. If that weren’t enough, Kathy didn’t share her own vision with the team or the other customers to whom she reported (such as marketing). A year into development, the game was demonstrated to a group of executives who were shocked at the direction the game had taken. It was not what they wanted to market. The disconnect between Kathy, the team, and senior management caused the project to lose six months of progress. Well done, Kathy!

Kathy demonstrated several guidelines for how an agile project can fail at the hands of a product owner.

GUIDELINE 10: Don’t communicate a vision for the product to the team or to the other stakeholders.

GUIDELINE 11: Don’t pay attention to the progress of each iteration and objectively evaluate the value of that progress.

GUIDELINE 12: Replace a plan document with a plan “in your head” that only you know.

One of the tenets of iterative develop ment is the discovery of the value of features being added as part of the whole. This is the reason that every iteration produces a potentially shippable release of the product. This is in stark contrast to plan-driven projects, which attempt to predict the utilization of resources so the product emerges complete from all the separate parts only at the end. When a product owner does not make that change, the team can quickly fail. It is just as critical to educate the product owner as it is to educate the team. Generally speaking, if you want to fail quickly, avoid training at all.

The crucial role of product owner often is balanced by someone else who acts as the team’s ScrumMaster or coach. On many successful projects, a certain amount of naturally occurring tension exists between product owner and ScrumMaster. A product owner always desires more, more, more features. The coach, by contrast, is responsible for monitoring the health of the team. If the team is being pushed too hard and is beginning
to get sloppy due to fatigue, the coach pushes back against the product owner’s desires for more. A good way to fail at agile is to eliminate this push-pull tension between the coach and product owner by following guideline 13.

GUIDELINE 13: Have one person share the roles of ScrumMaster (agile coach) and product owner. In fact, have this person also be an individual contributor on the team.

As you can see, failure at the product owner level is easily achieved through miscommunication, general ignorance of the team’s progress, and lack of education. You can compound that, if necessary, by having one person act in roles that are designed to balance each other. Following these guidelines to the letter is a great way to fail.

Process Issues
If all else succeeds, careful misapplication of process issues can bring down almost any agile project. Jon is a terrific example of a process nightmare, and he did most of his best sabotage without even knowing he was doing it. Jon was the lead developer for a Chicago-based team developing software designed to approve or reject loan applications. In addition to being the lead developer, he was also the ScrumMaster (note how he began by embracing guideline 13, which by itself can wreak havoc). Jon and his team were new to agile and were anxious to get rid of its unneeded parts. They immediately dispensed with daily standup meetings, reasoning that since the team sat in the same general area, most conversations could be heard over the six-foot-high cubicle walls.

They also decided that having automated unit tests was unnecessary. Since theirs was a new application, there was no chance of breaking old code, and since all new code would be fresh in everyone’s minds there would be little chance of accidentally breaking it. However, Jon and his coworkers did embrace refactoring and collective code ownership. Their new rule was that any programmer could change the code of any other programmer at any time. They soon learned that refactoring and collective code ownership can be very dangerous without the safety net of automated unit tests to make sure you aren’t breaking things while improving them. Jon and his team had unwittingly stumbled on these two guidelines for causing a team to fail at agile.

GUIDELINE 14: Start customizing an agile process before you’ve done it by the book.

GUIDELINE 15: Drop and customize important agile practices before fully understanding them.

An alternative to these guidelines is to dive into the practices without understanding why you’re doing them. As coaches, we encounter many teams who have learned a technique or been told to do something by someone and who then continued to do it even when they’d outgrown the technique (a subtle, yet effective,
subterfuge). This brings to mind the story of the newlywed wife who cuts a quarter inch off both ends of every roast she cooks. When her husband asks why she’s trimming the roast that way, she has no ready answer; she does it that way because it’s the way her mother always did it. Curious as to her mother’s
rationale, the wife calls her mother and asks why she taught her to cut the ends of the roast. Her mother says she only does it that way because her own mother taught her to do so. The young wife next calls her grandmother and asks why she cut a quarter inch off the end of every roast. Her grandmother tells her, “Because my roasting pan was too small. The roast wouldn’t fit any other way.” We capture this as our next guideline for failing with agile.

GUIDELINE 16: Slavishly follow agile practices without understanding their underlying principles.

If you haven’t been able to implement guidelines 14 through 16 and your agile project is succeeding despite your best efforts, you can bring even a successful project to a halt simply by changing nothing. What, you say? Change nothing? Follow the example of the StatusQ team. StatusQ, assigned to build a new Web-based reservation system, got off to a good start. Team members were new to agile but did a good level of research and sent a few of their people off to become certified ScrumMasters.

The project quickly benefited from the new practices. In a month, StatusQ had a simple Web site up and running and was able to demonstrate a few key interfaces that gave its customers a lot of confidence that their vision of an accessible and powerful reservation system would work.

StatusQ never held a retrospective at the end of each sprint. The ScrumMaster didn’t push for it because he didn’t see the need. Everything was already
working wonderfully well. You can encourage this behavior on your own team by complaining loudly to your Scrum- Master and team members if they try to hold a retrospective. Tell them that it’s a waste of time to sit and talk about a project that’s going well. Tell them that retrospectives only make sense when things are going wrong.

Over time, things at StatusQ started to slow down. The rate of change and the growing code base were creating maintenance problems. Changes to the system from the customers were supposed to be a benefit to them, but the code couldn’t keep up. Code stability became so bad that the project seemed to
be moving backward. Finally company management stepped in, put a halt to the changes, and finished the contract at half price. This team had unknowingly demonstrated our next two guidelines for failing at agile.

GUIDELINE 17: Don’t continually improve.

GUIDELINE 18: Don’t change the technical practices.

Company process issues that at first seem unrelated to the project can have a negative impact on morale and motivation. Consider the case of Dave, an up-and-coming artist who worked for a mobile phone game developer. He welcomed his company’s adoption of agile, as it made a lot of sense to him. The
new agile teams consisted of programmers, artists, designers, and a number of other people from numerous disciplines. Everyone relied on each other to create iterations of their game. If the artists did a good job, then the entire team looked good. Dave often dropped what he was doing to help his teammates iterate on the art to improve the game. This often came at the expense of his own work,but, for Dave, team goals came first.

Dave’s team did a great job and produced a hit title that sold many thousands of copies and earned the company substantial profits.

At the end of the year, Dave had his first performance review with the company’s lead artist. Dave was shocked to learn that his yearly bonus was small. Dave was told that he was judged by the senior artist in the company to have missed his art production goals. As it turns out, the senior artist was counting
the number of iteration task cards that Dave completed and based his judgment on that rather than on the real amount of work Dave completed.

Chagrined, Dave returned to his team vowing to make sure his task cards took priority over the needs of the team. Guideline 19 can be your backup plan for any enthusiastic agilists in your company.

GUIDELINE 19: Rather than align pay, incentives, job titles, promotions, and recognition with agile, create incentives for individuals to undermine teamwork and shared responsibility.

A tenet shared by all agile processes is that work is prioritized based on the value provided by each feature. Other factors, such as risk and knowledge creation, are considered, but the amount of
value delivered remains the dominant factor. A sure way to fail with agile is to ignore this tenet and instead follow guideline 20.

GUIDELINE 20: Convince yourself that you’ll be able to do all requested work, so the order of your work doesn’t matter.

There are, of course, other ways to fail in addition to those collected here. In your effort to undermine a successful agile project, you may have already discovered some on your own. Of course, you are probably keeping quiet about them because it’s critical that the sabotage not be detected until the bridge is blown. We are confident that, through diligent application of the guidelines here or those that only you know—or both—you will be able to plot the downfall ofyour next agile project.

Written by: Clinton Keith & Mike Cohn. Published in Better Software

About the author: Over the course of 15 years, Clinton Keith has worked on over a dozen of video game titles such as Midtown Madness and Midnight Club. Clint has been a project director, CTO and director of product development at several studios. He introduced the video game industry to agile development in 2003 and now coaches teams and studios around the world. He can be reached through his website at http://clintonkeith.com/

When it comes to projects, there are as many questions to answer as there are project teams, but “Where are we?” is by far the most popular. The key to understanding a project is to make regular measurements—both quantitative and qualitative—and display the measurements publicly. When project managers display these measurements as part of the project status, teams are able to adjust their work and proceed more successfully.

I like to call these measurements a “project dashboard.” You may not be able to show all the project measurements in one small area, such as one piece of paper, but taken together, the project measurements display your velocity, distance, consumption, and location—much as a car dashboard does.

Use Multi-dimension Measurements

It’s easy to measure some facets of a project, such as the project start date, the current date, and the desired release date and say, “We’re X percent of the way along,” because the project team has used that percentage of time. But if all you measure is the schedule, you’re almost guaranteed not to meet the desired deadline.

I like to measure a project along at least four out of six dimensions. I think of this as a project pyramid. (See Figure 1.)

Figure 1: Project pyramid

 The outside of the pyramid represents the constraints under which management has approved and funded the project. These project constraints are the work environment, the people and their capabilities, and the proposed project cost. I call them constraints because senior management tends to fix these attributes early in the project, and they tend to be difficult to change. Cost is the most likely to change, but in my experience it changes only when it becomes clear that the team can’t meet the desired deadline.

The project requirements are what your customers care about. (And yes, if you work in an IT group, it is likely that your customers are the same people who constrained the project’s cost, people, and environment.) Your customers care about what you’re going to deliver (the feature set), when they’ll receive it (time to release, the schedule), and how good that stuff is (defects). If you measure all sides of the pyramid, you will see a truer picture of your project than if you measure only one thing, such as schedule or defects, the two most common measurements I see.

Why Not Measure Earned Value?

So why not measure earned value? Earned value (taking credit for what you’ve been able to create in a specific amount of time) was developed to manage the tradeoff between measuring just the schedule and measuring what’s been accomplished. Earned value makes sense for products that can be created in self-contained pieces. You create a piece and measure how long it took and how much it cost (in people and time) to create that piece.

But for many software projects, it’s extremely difficult to calculate earned value. That’s because all parts of a software project are interdependent. Even if you implement feature by feature, which is as independently organized as you can make a software project, when you work on a new feature, you may have to return to completed work and change it. When you change completed work, it’s harder to determine the true earned value. Did you lose value because you changed something? Or, did you build on already-earned value? I have not worked on any project where it was possible to calculate earned value. In my experience, earned value is too often a fuzzy measurement for software projects.

Measure Project Completion

By using several measurements around the project pyramid, you can measure project completion. Project completion is a function of how accurate your original estimate was and how much progress you’ve made. But measuring only the schedule progress is not good enough. The only accurate way to measure progress for a software project is to measure how many features the project team has completed, how good those features are, and how many features are left to implement.

I once assessed a project in an organization where the developers had met every single date in the project schedules, but the testers were consistently late. Seems suspicious, doesn’t it? The developers hadn’t actually met any milestones at all—they checked in stubs and fixed the code when the testers reported defects. But because the project managers only looked at the dates—and never measured anything but the dates—the developers could say they had met the deadlines—without actually meeting them.

The only accurate way to measure progress for a software project is to measure how many features the project team has completed, how good those features are, and how many features are left to implement. As shown in the velocity chart in Figure 2, the number of features grew over the course of the project. The project team started with fifty features but released sixty-five features. If the team hadn’t tracked their progress including the number of features, they would not have been able to explain to their management why things took “so long.”

Figure 2: A velocity chart can be used to track schedule progress .

If I’m not implementing by feature, I like to use progress toward release criteria as a project completion measurement. Table 1 is an example of how I use release criteria to track project completion—or the lack thereof:

Table 1: Use release criteria to track project completion.

Release criteria are a late-in-the-project measurement. Even if you start assessing release criteria progress at the beginning of a project, most often, the release criteria data are available close to the end of the project.

No matter what lifecycle model you’ve selected for your project, to determine how good your initial estimate was, you can use Estimation Quality Factor (EQF), originally described by Tom DeMarco in Controlling Software Projects. At periodic intervals during the project, the project team answers the question “When do you think we’ll be done?” Each data point is the consensus agreement on when the project team believes the project will be finished. At the end of the project, draw a line backward from the release date to the beginning of the project. The area between the line you drew and the when-will-we-be-finished line is how far off your estimation was. This is a great technique for people to use as feedback on their individual estimates. But even if you don’t use it for feedback, it’s a great technique for the project manager to see what’s going on.

Figure 3: Example EQF for a project

Figure 3 is a chart of an EQF for a project that was originally supposed to be nine months long. For the first couple of months, when the project manager asked when people thought they’d finish, they said “September 1.” And for a couple of months, they were optimistic, thinking that they might finish early. But during the fifth month, team members realized they didn’t know enough about some of the requirements. What they discovered changed the architecture and pushed out the date. For the next few months, they still weren’t sure of the date. They realized in the last three months of the project that, because of the changing architecture, they were encountering many defects they hadn’t anticipated. So, evaluating EQF, a qualitative metric, was helpful to the project manager and the project team as a check against the progress charts.

Schedule estimates are just guesses, so anything you can do to show and then explain why your schedule varies from the initial plan will be helpful to anyone who wants to know “where are we?”

Collect a Variety of Project Measurements

Project completion measurements may be all your managers want to see, but if you’re a project manager or a technical lead on a project team, I’m sure you’d like some early warning signs that the schedule may not be accurate. To keep my finger on the pulse of a project, I monitor several measurements:

• Schedule estimates and actuals, aside from EQF
• When people (with the appropriate capabilities) are assigned to the project versus when they are needed
• Requirements changes throughout the project
• Fault feedback ratio throughout the project
• Cost to fix a defect throughout the project
• Defect find/close/remaining open rates throughout the project

Measure the Schedule When It’s All You’ve Got

I don’t use just Gantt charts to measure a schedule. Instead, I look at when the project team expected to meet a particular milestone and when they actually met that milestone. If the project team starts the project late (no matter what the first milestone is), that project is not going to meet the desired end date. Time lost is never going to be regained. Figure 4 shows what a comparison of schedule estimates and reality looks like.

Figure 4: Schedule Estimates vs. Actuals

This project is a modified waterfall lifecycle (the next phase can start without the previous phase being complete), but there are no iterations. Notice that the project started a full month late. When the project manager posted this chart, he also said this to senior management, “Don’t expect us to pull in the schedule by a month. We started late; we can’t make up the time.” To the project team he said, “I’d like you to work as intensely as you can, without working overtime and getting tired. We don’t have time for you to make mistakes. Do the best job as quickly as you can, and we’ll keep tracking where we are.”

See When Qualified People Actually Work on the Project

Too many projects start starved of resources. This can happen if some of the people are still working on a previous project, if people are yanked off partway through the project, or if your project is competing with several others for people’s time. The problem with starving a project is that no matter how hard people work when they are working on the project, they can’t make progress if they are assigned elsewhere or are attempting to multi-task on several projects. Figure 5 shows a project where the total number of planned person-months (666) was 75 percent of the actual person-months (878). Unfortunately, the team’s output was about 66 percent of the desired result.

Figure 5 : Tracking People’s Actual Assignment to the project

For more expense (about 1.3 times the original planned cost), the team delivered fewer features (0.3 times the original feature set). You might be asking why the project team would deliver less than planned for more cost? This project used a staged delivery lifecycle, where requirements, analysis, and architecture were timeboxed. The project team could obtain a good idea about the requirements and their effect on the architecture, but not know all the requirements in detail or know the implications of those requirements on the architecture. The original plan was to spend the first two months obtaining a good idea and the next two months performing an initial iteration to make sure the rest of the project would succeed. In order to be successful, the project plan required all the people planned in those first four months to perform all the initial investigation and iteration work. Since the people were not available and the end date was non-negotiable, the project team needed more people to prototype and iterate in parallel.

As people prototyped and iterated, they found mistakes—work that had not been completed in the initial timeboxing and iteration. Team members decided they would rather release a product that worked a little rather than release a product that had all the features, most of which didn’t work.

This chart supplied the project manager with opportunities throughout the project—and when planning for the next project—to explain to senior management the problem of starving a project.

If you ever start your projects starved of people who are capable of performing at 100 percent, this figure can help explain the consequences of that decision.

Determine the Rate of Change on Your Project

You may be working with people who are uncomfortable with velocity charts. Or, they may not believe the impact that some changes have on requirements. In that case, you can use a requirements change chart. (See Figure 6.)

Figure 6: Requirements Changes by Week

In this case, I was the project manager. I had a simple criterion for deciding if the requirements change was major or minor. A minor change affected one module, and a major change required changes to more than one module. To make this decision, I used the principle that “interface changes between modules tend to create defects.”

In this chart there are lots of small changes—something most of us expect on projects. But we also encountered some major requirements changes late in the project (Week 22). When I saw these requirements changes, I was able to explain to senior management that either the project would be later than we expected or the number of defects would rise. But with these changes, it was clear that the original date and the original feature set with the small number of expected defects was not possible.

See if the Developers Are Making Progress or Spinning Their Wheels

Once the project team is writing code, you can measure the fault feedback ratio (FFR). The FFR is the number of bad fixes to the total number of fixes. In my experience an FFR of 10 percent or more says that the developers are having trouble making progress.

Figure 7: Fault Feedback Ratio compared to number of Defects Closed

I like to measure the FFR on a weekly basis. I use FFR as data to initiate a discussion with the developers and testers. If I see a week where the FFR is high, I first check to see how many total problems were fixed that week. If only four problems were fixed and one was a bad fix, the developers and testers are probably OK. But if I see twenty defects fixed and five of them were bad fixes (25 percent), it’s more likely that somebody or a few somebodies are having trouble. In Figure 7, notice that the FFR starts to get high around Week 6 and stays over 10 percent until Week 13. Once the project team hit the second week of high FFR, the project manager instituted peer review on all fixes. That helped, but there was a delay between the start of peer review and the reduction of FFR back to numbers where the fixes didn’t interfere with progress.

To identify trouble areas, I first ask the developers if they are running into trouble with their fixes. I generally phrase the question this way: “When you fix something here, does a problem pop up over there?” I’ll ask other questions, all leading to asking the developers if they need any resources to fix this problem altogether. If I hear that the developers want to redesign a module, we discuss the issues for that redesign.

My next question is for the testers: “Are you able to define all the conditions that create this problem?” I start with those questions to see if the developers are fixing one piece of the problem at a time, or if the testers understand the system sufficiently to test thoroughly enough.

Measure How Much It Costs You to Find and Fix Problems

One key measure is how long it takes the project team to find and fix problems. You’ve probably seen “industry standard numbers” that look something like this:

The idea here is that it costs you one unit to fix a problem in the requirements phase, ten units to fix a problem in design, one hundred units in code, 1,000 units in test, and 10,000 units in post-release. We normally think of units as dollars or some other form of currency.

I’ve measured cost to fix a defect, and the numbers I find are different. Table 2 shows costs from a couple of projects:

Table 2: Measured Cost to Fix a Defect for Two Projects

Remember, it’s not just the cost per defect; it’s the cost per defect times the total number of defects. If you’re not looking at the overall cost, you can’t know where to spend your time. Based on cost to fix a defect from previous projects, you might decide to be proactive and use inspections of key project documents, test-driven development, or pair-programming for the more challenging defects. Or you might decide to monitor cost to fix a defect and take a more reactive response, such as peer review of fixes or inspection of all code.

If you haven’t performed any proactive defect-finding activities, the cost to find a defect is fairly small. But the cost to fix can be high, and the overall cost to fix all the defects is very large. If you have been proactive using techniques such as test-driven development, pair-programming, inspections, or peer reviews, the cost to find a defect can be higher—because you’ve already looked for defects. But the cost to fix a defect tends to be lower when a project team has been proactive in trying to find defects early. And the overall number of defects is lower, lowering your total cost to fix defects for a particular release.

I monitor cost to find and fix so I can see if the developers or testers are surprised by what’s in the code base. I have a couple of rules of thumb, assuming the developers have not been proactively looking for defects:

• The longer it takes developers to fix a problem, the more likely it is that the developers are afraid of touching parts of the system or that the developers don’t understand parts of the system.
• The longer it takes the testers to find problems, the less they know about the product or the less they know about multiple techniques to test the product.

The longer a defect takes to fix, the more careful we’ll have to be when deciding what to fix just before release.

Understand if the Developers and the Testers are Making Progress with Defects

Almost everyone measures defect trends. I’ve seen some intricate defect trend charts, but my favorite chart shows just three things: number of new defects found per week, number of closed defects per week, and the number of remaining open defects per week. (See Figure 8.) I specifically do not chart defects by priority. I find that the project team and senior management become too willing to play the promotion/demotion game when I chart defects by priority. And the developers have to read through all the defects, even if they are supposedly a lower priority. So, I just count all the defects.

I count the number of remaining open defects so I can see when the close rate passes the find rate, enough so that the number of remaining open defects starts to decrease. I look for the knee of that remaining open defects curve, knowing that as the slope of the remaining number of open defects goes negative, the risk of release lessens.

Figure 8 : Defect Trends over a Project

Display Qualitative Data

It would be easy if all the project data could be displayed on trend charts. But you need a different kind of chart, especially when you’re trying to explain the status of something. I’ve used progress charts like the one in Table 3 when trying to explain the progress of algorithm development, performance scenarios, and testing.

Table 3 : Test Progress Chart

Displaying Data

I try to be consistent in my charts. Red is bad; green is good. Up is bad; down is good. Bad and good are very judgmental words, especially when applied to data. After all, data just is. But you may not be able to explain your data to everyone all the time. In that case, it’s helpful if people know how to read your charts. Tufte’s The Visual Display of Quantitative Information is a great resource, especially when your charts will be read and interpreted by other people.

In Data We Trust

Without data, you’re just another person with just another opinion. And while your opinion might be good, it’s not the same as having data. When you measure around your project pyramid, you’re gathering data that not only will explain where you are in this project but also data that will help you plan for the next project.

StickyNotes

References

1. Rothman, Johanna. “Pragmatic Project Management Workshop.” 1999-2005.
2. Grady, Robert. Practical Software Metrics for Project Management and Process Improvement. Englewood Cliffs, NJ, Prentice Hall, 1992.
3. Rothman, Johanna. “Release Criteria: Is This Software Done?” STQE, March/April 2002.
4. DeMarco, Tom. Controlling Software Projects: Management, Measurement and Estimation. Prentice Hall, 1982.
5. Rothman, Johanna. “What Does it Cost to Fix a Defect?” stickyminds.com, February 7, 2002.
6. Rothman, Johanna. “By the Dashboard Light.” stickyminds.com, July 9, 2004.
7. Tufte, Edward, R. The Visual Display of Quantitative Information, Cheshire, CT, Graphics Press, 2001.

Since the publication of Kent Beck’s Extreme Programming Explained,1 agile processes have grown increasingly popular. Agile processes  allow  for  changing  require- ments throughout the development cycle and stress collaboration between software devel- opers and customers and early product delivery. The “Agile Manifesto” establishes a common framework for these processes: Value individuals and interactions over processes and tools, working software over comprehensive documentation, cus- tomer collaboration over contract negotiation, and responding to change over following a plan.2  The processes most commonly considered agile include Extreme Programming (XP),1 Lean Development,3 Crystal,4  and Scrum.5-6

In Scrum, projects progress in a series of month- long iterations called sprints. Development teams meet with the client, or product owner, before each sprint to prioritize the work to be done and select the tasks the team can complete in the upcoming sprint. During the sprint, the team stays on track by holding brief daily meetings. At the end of each sprint, the team delivers a potentially shippable product increment. Scrum is ideally suited for pro- jects  with  rapidly  changing  or  highly  emergent requirements such as Web projects or product devel- opment for new markets.

Over the past four years, we have introduced Scrum to seven organizations in four states. Some of the projects were complex and involved distrib- uted  teams.  Others  were  straightforward  and involved small, colocated teams. However, even the simple projects reached across many departments or functional areas. A failure to sell the process change to any one area can negatively impact the project’s outcome.

Through trial and error, we have discovered sev- eral approaches for successfully introducing agile processes to organizations.

DEVELOPERS
Most developers respond to the proposed intro- duction of an agile process with the appropriate combination of skepticism, enthusiasm, and cau- tious optimism. Other developers, however, either resist the change or overzealously jump into the pro- ject without enough forethought. Either reaction can cause problems.

Resistance
In general, agile processes value code production more than plan-driven processes do. In a plan-dri- ven   process,   developers   might   treat   Unified Modeling Language designs and other noncode items as first-class artifacts. In an agile process, however, these items usually exist only to support the coding activity.

While  introducing  Scrum  to  various  project teams,  we  invariably  found  programmers  who enjoy producing noncode artifacts far more than they are willing to admit. We also encountered pro- grammers who measure their contribution to a pro- ject by the number of meetings they attend. These programmers go beyond “analysis paralysis” and actively seek opportunities to add formalized tasks back into an agile process. One programmer, for attempted to coerce his peers into generating the document for hundreds of cases when it was called for in perhaps a dozen.

In such situations, it is best not to intervene. The of these activities and will not adopt them if they do not help the overall development effort.

Micromanagement
A surprising number of developers view using agile  processes  as  an  attempt  to  micromanage. Because approaches like Scrum and XP accelerate project cycles, developers typically interact with their managers more frequently but for shorter periods. In a plan-driven process, a manager might go a full week without talking with a particular developer, but daily contact is the norm in most agile processes. Developers who view agile processes as micro- management  tend  to  perceive  interactions  with their project managers as being about due dates and missed deadlines. To avoid this problem, project managers  should  constantly  demonstrate  their desire to remove obstacles as quickly as possible and   not   complain   if   a   task   takes   too   long. Managers can be surprised, but should not be judg- mental, when told that a task will take longer than originally thought.

Transitioning from a heavyweight process
Some   developers   we   encountered   preferred heavyweight plan-driven processes because they believe they looked better on a resume. Because these individuals do not have deeply held convic- tions about the process’s value, they can eventually be swayed by their coworkers’ opinions and actions. A gradual transition from a heavyweight to an agile process can make the change easier on the development team. Some teams, when first intro- duced to Scrum, are overwhelmed to the point of inaction by the freedom of not having a day-by-day Gantt chart directing their work.
We have helped teams ease into Scrum by defin- ing a set of sprint types:

•  prototyping,
•  requirements capture,
•  analysis and design,
•  implementation, and
•  stabilization.

We then work with the teams to define the arti- facts that will result from each sprint type. Using sprint types introduces just enough formality through the project. As the teams become more adept with the informality of the agile process, they gradually drop the sprint types concept.

Distributed development
Teams using agile processes tend to make decisions  more  quickly  than  plan-driven teams, relying on more frequent (and usually informal)  communication  to  support  this pace.

A failed attempt to use an agile process in a pro- ject with sites 2,000 miles apart taught us that orga- nizations should resist distributed development for at least the first two or three months after initiat- ing an agile process. The companies involved in the merger that initiated the project needed to resolve their political and cultural issues before developers could succeed with a project shared across multi- ple cities.
If distributed teams must be combined, bringing as many people as possible together for the first week or two of the project can increase the likeli- hood of success. We have successfully used this approach on multiple distributed projects.

The need for top talent
Barry Boehm’s principle of top talent, “use bet- ter  and  fewer  people,”7   is  central  to  an  agile process. Agile processes strip nonessential activi- ties from projects, leaving developers more time to develop.
Although the difference in productivity between the best and worst programmers on a team may exceed the documented ratio of 10:1,8 the produc- tivity difference matters most when the program- mers are working on tasks essential to software delivery.  Productivity  differences  are  irrelevant when the programmers are engaged in nonessen- tial activities.
When fully engaged and comfortable with an agile  process,  a  development  team  moves  very quickly. Too many slow workers either slow the entire team or end up left behind by their faster col- leagues.

Overzealous teams
One team we worked with was overly enthusi- astic about a move to XP. At the project’s onset, team members aggressively began documenting requirements by writing user stories, planning iter- ations,  and  pairing  up  for  programming  tasks.

They even moved out of their existing space Agile processes and into an adjacent abandoned building better suited for XP. Unfortunately, they did all do not imply of this so quickly that the rest of the organization had no idea what they were doing,resulting in a number of problems. Although agile processes promise greater productivity once in place, productivity may decrease during the transition while the team learns new techniques. Not having anticipated this decreased productivity, the team chose to redouble its efforts when it occurred. Agile processes do not imply making decisions without forethought, a distinction this overzealous team missed in its quest for speed and agility. To this team, Beck’s recommendation to “put in what you need when you need it”1 meant they needed to think only about an hour ahead. They didn’t have the discipline XP requires, and, while paying lip service to XP, they were actually doing nothing more than hacking.9 
 
Overzealousness also caused the team to split into two camps: the overzealous team members and a group that knew decisions were being made too quickly and often incorrectly. Much like the tortoise and the hare, these two subteams pursued the project differently. After the project’s failure, it took a while to convince both groups to jointly pursue an agile process, albeit one that was “less agile” than the overzealous members initially wanted.

Testers 
Writing source code is a primary activity in any development process, but it is especially important in agile processes: “Code is the one artifact that development absolutely cannot live without.”1 
 
Agile processes do not have separate coding and testing phases; rather, code written during an iteration must be tested and debugged during that iteration. Testers and programmers work more closely earlier in an agile process than in other processes. Thus, testers and other nonprogrammers must be carefully integrated into any agile project in which they participate. 
 
Initially, testers, even more than programmers,tend to view an agile process as micromanagement. Before the adoption of an agile process, many testers (especially those in organizations without a separate and dedicated testing group) do not receive much attention from managers. Test activities are often relegated to a single line item on a project plan. 
 
In plan-driven projects, testing tends to occur without explicit notice from a project manager, so testers  are  not  used  to  the  extra  attention  they receive on most agile process projects. As with pro-grammers, testers will see over time that an agile process is not synonymous with micromanagement.

We have encountered testers who secretly want to be programmers and use a project’s early itera-tions to sneak in some programming. We also have worked with testers who either volunteer or are coerced into writing unit tests for programmers.

Especially during a project’s earliest iterations, you should discourage testers from such inappropriate activities. First, if the tester knows enough about pro-gramming to program and you need another pro-grammer, hire the tester. Second, writing a unit test for someone else may result in a useful test, but it almost certainly loses some of the white-box advan-tages inherent in self-written unit tests.

UPPER MANAGEMENT
Upper management often presents unique chal-lenges to organizations wishing to move toward an agile process. Upper-management concerns gener-ally fall into four categories:

• How can we promise new features to cus-tomers?

• How can we track progress?

• How will the agile process impact other groups?

• When does the project end?

Many managers, particularly those at higher lev-els, are reluctant to surrender the feeling of control that Gantt charts and other plan-driven process arti-facts give them. Similarly, they may be comforted by the development group’s promise to deliver an exact amount of functionality on a specified date, even if they know the group won’t be able to do so.

Customer commitments
Managers who worry that an agile process will mean they can’t make product commitments must understand that any past project plan that implied guarantees about delivery date, cost, and func-tionality was either wrong, heavily padded, or both.

In organizations with a history of incorrect pro-ject estimates, it might not be difficult to convince upper management that an agile process is worth trying. If a software group has a record of on-time delivery, however, you must convince upper man-agement that using an agile process could have resulted in projects being completed either sooner or with fewer resources.10-12

Drawing a typical cost, date, and feature triangle usually can persuade upper management that such commitments are an illusion. Once upper management realizes that past commitments were mostly combinations of good luck and padded esti-mates, they become very interested in any process that promises greater efficiency.

Tracking progress
Plan-driven processes appeal to many upper managers because they facilitate progress tracking. A manager can track a process that results in numerous documents by simply asking if the nec-essary documents have been produced.

If a Software Test Plan is called for, a first level of tracking can occur when the manager verifies its existence. A second level of tracking can occur when the manager weighs the document, and a third if the manager reads it.

To persuade upper managers that agile processes allow adequate project tracking, we usually create two or more model status reports based entirely on fictional data about the project an organization is considering for an agile process. The reports depict a fictional two- to four-week project cycle.

A typical status report for a Scrum process pro-ject includes a list of key dates, a two- to five-para-graph commentary on the project’s state, a burn-down chart comparing progress to planned work, key metrics (defect inflow, percentage of tests passed, and so on) appropriate to the project’s current state, and a list of key risks. The upper-management decision makers we have worked with have found this type of status reporting satisfactory.

Impact on other groups
Some upper managers have expressed concern that although an agile process might benefit the development group, it can adversely affect one or more other groups. This concern becomes unhealthy when another group’s processes nega-tively impact the development team’s work. For example, one software engineering group wanted to use Scrum, while the product management group that provided all specifications and requirements wanted to continue with a heavyweight waterfall approach. The CEO saw no problem in letting each group pursue its independent strategies. The result was 2,000 pages of detailed product specifications fed into a development process that needed work prioritized in monthlong units.

The software engineering group had to guess pri-orities from the product management group’s three-to four-month task lists. Once the software engi-neering group was accustomed to Scrum, however, they moved through the requirements faster than the  other  group  could  write  new  requirements.

When introducing an agile process into an organization, upper management must understand and agree on how this will impact groups outside the development group. If they don’t, and if they can’t agree on how to resolve differences of opinion, most efforts will likely fail.

Project completion
Finally,  upper  management  commonly fears that a project will go on forever. Most managers are comfortable with a model in which project budgets are approved and the project remains within the budget confines. They are less comfortable when told that project iterations will persist as long as the customer or a customer proxy continues to identify high-priority, high-value work.

Wrapping budgeting and strategic-planning activities around the project can address these concerns. For example, we estimated one commercial project would take from nine to 15 months—a fairly imprecise estimate because we didn’t know exactly what features  the  completed  system  would  include. Regardless of how many bells and whistles the client desired, however, we felt reasonably sure that a suitable  initial  release  would  be  available  in  nine months. We therefore convinced upper management to fund a nine-month development effort with the agreement that additional funding would be discussed near the end of that period.

HUMAN RESOURCES
You might think that a human resources department would have no interest in one group’s transition to an agile development process, but this is not the case. On a project that was transitioning to XP,  two programmers approached the HR department with complaints about pair programming—two programmers sharing a keyboard and monitor and writing code in tandem—which, of course, sounded odd and unproductive to HR. Because we hadn’t told HR about the process change, we were immediately in the difficult position of having to explain why pair programming made sense.

Another time, a small subset of programmers complained to HR that they didn’t like how a project was being managed. The complaints stemmed from their unwillingness to consider or try anything new or different. The programmers were familiar with  plan-driven  processes,  and  anything  else
seemed too chaotic. This was in 1999, before XP had become an intriguing buzzword, before the Agile Alliance2 had been formed, and when Scrum was only beginning to be documented.

The HR department must be told when a group is transitioning to an agile process. When told, however, the HR department may raise its own concerns, centering on an agile process’s imprecise deliverables and dynamic goals. Many HR depart-ments require corrective action plans, which cite specific deliverables and deadlines that can result in the employee’s termination if not met.

It is difficult to shoehorn tasks from an XP iter-ation or Scrum sprint into a deterministic correc-tive action plan. However, we have found that by proactively working with HR, we can sufficiently define tasks and deadlines that both satisfy HR and let the project follow an agile process.

How an agile process is introduced into an orga-Hnization will significantly impact the ultimate success  of  the  process  change.  Any  new process is likely to appeal to some developers, who are excited to be among the first to try it. Similarly, this  newness  is  an  obstacle  to  developers  who oppose change.

Agile processes have continued to evolve over the past four years, and approaches that worked in one case have not worked in another. As experience in the introduction of object technology into compa-nies in the late 1980s and early 1990s led to the dis-covery of best practices in introducing that technology, we expect an understanding to arise over the next few years for agile processes. ■

References
1. K. Beck, Extreme Programming Explained, Addison-Wesley, 2000.
2. K. Beck et al., “Manifesto for Agile Software Devel-opment,” Feb. 2001; www.agilemanifesto.org.
3. M. Poppendieck and T. Poppendieck, Lean Software Development, Addison-Wesley, 2003.
4. A. Cockburn, Agile Software Development, Addi-son-Wesley, 2002.
5. M. Cohn, “The Scrum Development Process”; www.mountaingoatsoftware.com/scrum.
6. K. Schwaber and M. Beedle, Agile Software Devel-opment with Scrum, Prentice Hall, 2002.
7. B. Boehm, Software Engineering Economics, Pren-tice Hall, 1981.
8. F. Brooks Jr., The Mythical Man-Month, Addison-Wesley, 1975.
9. B. Boehm, “Get Ready for Agile Methods, with Care,” Computer, Jan. 2002, pp. 64-69.10. A. Cockburn and J. Highsmith, “Agile Software Development: The People Factor,” Computer, Nov. 2001, pp. 131-133.
11. M. Cohn, “The Upside of Downsizing,” Software Test and Quality Eng., Jan. 2003, pp. 18-21.
12. Shine Technologies, “Agile Methodologies Survey”; www.shinetech.com/agile_survey_results.jsp, Jan. 2003.

Written By: Mike Cohn & Doris Ford

About the author: Mike Cohn is the founder of Mountain Goat Software, an agile consulting and training company. He is the author of Succeeding with Agile: Software Development using Scrum, Agile Estimating and Planning and User Stories Applied for Agile Software Development. With more than twenty years of experience, Mike has previously been a technology executive in companies of various sizes—from startup to Fortune 40. A frequent magazine contributor and conference speaker, Mike is a founding member of the Scrum Alliance and the Agile Alliance. He can be reached through his website at www.mountaingoatsoftware.com.

About the author: Doris Ford is the president of Precision Projects. Her current research interests include software projectmanagement, project metric development, and tracking methodologies. Ford received an MBA from Regis University. She is a member of the Project Management Institute. Contact her at dtford@yahoo.com.

Abstract

Project management can be described as the activity of bringing all participants from within a department to successfully complete a product deliverable. Iterative planning and tracking are techniques used by some project managers to avoid having to choose between reducing the number of features or extending the schedule.

Introduction

Because software is ephemeral, software projects are frequently difficult to plan, track, and assess. Iterative project management techniques help make the obscure clearer.

Most successful project managers know how to set up a project plan. They know what the standard milestones or events for the project need to be (O’Connell, 1996), and they plan the project accordingly. They plan the schedule according to a specific critical path (generally tasks). McConnell (McConnell, 1996) and others have shown that once a project has missed a milestone, the project’s staff cannot “make up” the time. Project managers may face the choice between extending the schedule and dropping the features. The management part of project management is required to manage the schedule and include the features.

There is an alternative to the blind choice of extending the schedule or dropping features. As a project manager, if you can “chunk” the features, and give yourself sufficient flexibility in learning about the features and project scheduling, then you can redirect the critical path, and still make the schedule with the planned features. This method of developing a number of small independent features, and frequent replanning is iterative project management.

This paper presents an iterative project scheduling technique together with two example releases from an organization.

Initial Project Planning

Senior management frequently fixes the ship dates without a good knowledge of the features to be produced. Naturally, the engineers decry this as a terrible, awful thing. Planning and expecting to completely meet a fixed schedule project without adequate feature knowledge is truly is a terrible, awful thing. For example, imagine this scenario.

Dan, the project manager, has just talked to senior management. “Those **&&** just did it to me again. They told me to ship this next release in 4 months. Our competition just announced availability in 8 months. Now we need to announce availability in less than 6 months. We don’t even know what it’s going to take to design this feature, never mind implement it within this architecture. How the heck can I sell this to the engineers? What am I going to tell my project team? They’re going to kill me- or what’s worse, they’ll all walk out. How could senior management do this to us? Don’t they know what it’s like to develop software?”

It’s not that senior management is bad or stupid. Commercial companies have significant market forces that may prevent them from fully understanding what they are requesting of the product developers. Market forces drive companies to make choices before the company is really ready to do so. Iterative project planning allows a company to get started on a project when only the major issues of the feature set are understood, but the ship dates are set in stone.

Critical Paths

There are multiple critical paths in a given project. The tasklist generates a particular critical path. The people working on the project create another critical path. And, hard resource availability creates yet another critical path. The true project critical path is the critical path through all three views: tasks, people, and resources.

During the initial planning phase of many projects, the tasks and events are planned, and with any luck, the task critical path emerges. Many project managers are also aware that people and hard resources (i.e. machines, networks, etc.) have an impact on the critical path, and they plan for using these scarce resources appropriately.(Goldratt, 1997)

In a project where the project manager and the technical staff do not have sufficient knowledge of the full feature set under development, a traditional approach does not guarantee success. The traditional approach assumes the project manager knows and understands the critical paths of tasks, people, and resources. In a less-fully specified project, it is unlikely that the project manager will know all the critical paths. The project manager will probably be surprised by new tasks that arise, unforeseen tasks, or new expertise may have to be developed, and new resources may be required.

When project knowledge is imperfect an iterative approach is more successful:

1. Plan the major milestones. Estimate the feature freeze, code freeze, system test freeze, beta ship and product ship dates. Determine the criteria by which the project staff can agree that these milestones have occurred.
2. Plan each segment of the project as it crystallizes, staying at least four weeks ahead of the current state.
3. As each project segment completes, the project manager and technical staff have a better understanding of the project and the eventual product, so more complete planning can take place. By the time the project has reached the feature freeze milestone, the tasks required to get to code freeze are well understood. By the time code freeze is reached, the rest of schedule can be laid out and planned.

This iterative approach reduces uncertainty for the current project work, and allows replanning of the critical path at a number of points in the project.

Milestone Definitions

This set of milestones is useful for defining software project schedules:

For small projects, there may be only one of each freeze and Beta ship. For larger or more complex projects, functionality may be grouped so that part of the product is ready for code freeze while part of the product has still not met feature freeze.

Milestone Planning and Criteria

Effective project managers and software engineers understand that a general approach of

1. Requirements planning
2. Feature definition (leading to feature freeze)
3. Design and implementation (leading to code freeze)
4. Verification and Validation (leading to ship)

is a time-effective and cost-effective way to implement a project. In addition, early and often reviews and inspections will reduce project time (Gilb, 1993). Project managers following this technique can get a better handle on the milestones of feature freeze, code freeze, system test, beta freeze, and ship freeze.

In an iteratively planned project, it is critical that the project team agrees on what each milestone means. The project manager depends on accurate information about the current state of tasks from the project team. How can the project be successful if the project manager and team do not understand what the milestones mean?

To use the iterative planning technique, the project manager plans the major milestones (e.g. feature freeze, code freeze, system test, beta freeze, and ship freeze), and then iterates on the work between the milestones.

(Re)Planning the Next Project Phase

Even for an iteratively-planned project, some tasks are clearly defined in each phase. For example, if a formal beta test is planned, then all the pre-beta tasks need to be completed before beta can start. These tasks can and should be planned in the initial project schedule. Any tasks that can be planned in advance should be planned.

One of the benefits of not doing detailed planning of the next major phase is that the project can advance more quickly. Some people are intimidated by a large schedule with many tasks (Maguire, 1994). Either they think they can’t possibly make any progress, or they figure since there are so many tasks, if their task slips, it’s not a big deal. However, any task slippage diminishes the ability to replan the rest of the project. If the project manager shows people a project plan with less detail, and continually asks them for more detail, they are more motivated to complete their tasks. My experience has been that people are anxious to complete their work, and get the next batch of work. When there is huge task list of everything that needs to be done, people get bogged down.

By planning the current phase in detail, and gradually increasing the detail on the next project phase, people can see how progress is being made, and they come up with possibilities the project manager may have missed to accelerate the project.

In a fixed-ship schedule, the project manager is always looking for ways to advance the project. All too often in traditionally planned projects, project advances (tasks finishing early) are wasted (Goldratt, 1997). The reasons for this are the following:

1. There is no rush to start this task, so the task owner starts at the last minute. (Goldratt calls this “Student Syndrome”, waiting until the last possible minute to start the assignment.)
2. When people multitask between different tasks, they waste time changing context between tasks. (See (DeMarco, 1987), (Weinberg, 1994), and (Weinberg, 1997) for an excellent explanations about the damages of context switching on effective work.)
3. Dependencies between steps can waste all advances, if the dependencies between steps and resources are not uncovered and planned for before the tasks are started.

In an iteratively planned project, no one person has a huge list of tasks, so lack of progress is more visible. Since there are fewer tasks, there is incentive to start each task as quickly as possible, so that forward progress can be reported.

A fixed-schedule project has a deep sense of urgency, so the project manager can reduce the requests for and effects of multi-project multitasking. Using an iterative planning approach, the schedule becomes more and more detailed over time. The dependencies are uncovered early, and replanning can occur when more dependencies are uncovered.

Replanning

Replanning is necessary when there is a project advance or delay. Project delays propagate to later project steps (Goldratt, 1997). Time can never made up, only plans can change.

In traditional completely-planned projects, there are only two alternatives to project delays (Weinberg, 1994):

1. Reduce the number of features
2. Slip the schedule

If you understand precisely what it will take to complete the features, and you understand the current project state, there are no other alternatives. The reason is that the project critical path is fixed.

Shifting the Critical Path

In a less well-defined project, however, there are alternatives. For example, if you understand the current critical path by task and person performing that task, there may be an alternative to who performs the task at what time.

If the critical path cannot be shifted, then the project manager only has the two choices above- reducing features or slipping schedule.

Example

This is two examples of iterative project planning and tracking with a small group developing a middleware communications application. For the purposes of this discussion, we will call the product “Messenger”. In this case, senior management did not fully understand features, and the ship dates were fixed.

The original project milestone dates were:

By 3/15/96, the project was in this state:

1. The project manager had not written a project plan (the prose defining the features, approach, and release criteria).

2. Feature freeze had not occurred. Two of the three major features for the release had not been adequately defined technically.

3. A task list existed, but many tasks were defined as three to four weeks duration. In reality, the project team was slipping about a week every two calendar weeks. The original task list only had about a dozen more tasks than the excerpt above.

The technical staff were working on what they thought was important to do, but it turned out they were not working on the project’s critical path. They were working on whatever was interesting to them, and on customer problems (Rothman, 1997).

By April 1, it was clear that a mid-May product ship date was not going to be possible. The original project manager was replaced in April 1996 by a more experienced manager who then worked with the technical staff to create a new project plan.

The first project schedule from the second project manager looked like this:

The new underlying task list had substantial detail for the feature freeze and code freeze milestones. There was little detail past the “Start System test” milestone. There was very little detail in the beta test phase, primarily because Feature Freeze had not been met yet. However, the major milestones, and some of the specifics of the end game (manufacturing dates, etc.) were specified, because they were known, and their dependencies were understood. The plan was to get to the System test freeze date. If the system test entry and beta entry criteria could be met, the rest of the schedule could be planned. The project team understood that their first priority was to get the software features implemented and stable.

Within two weeks, by 4/15/96, it was obvious that beta test was not going to start on 4/22/96. These things happened:

• Senior management and the project manager discussed the promises made about this product release to the customers and the press. The external promises were for “Second quarter 1996″, rather than a hard date.
• The customers were willing to take beta software that had not been through system test.
• Senior management understood that the project was about three months late.

These realizations allowed the real replanning to start. In mid-April, not all the features were fully designed. The project team worked with the project manager to determine what would define the feature freeze, and came to (not quite bloody) agreement.

In mid-May, the milestones were:

At the April project assessment, based on the progress and current slip rate, it was not clear that the project could complete before August. In July, senior management was overjoyed that the project was less than three full months late. The customers were thrilled. They had never received a Messenger release this close to on time, with as few defects as this release had.

The original missed time could not be made up, but iterative planning was useful for containing the project slips.

This same project team then started another project with initial dates:

In this case, there was substantial task list detail for the feature freeze and part of the code freeze milestones. There were no technical tasks listed for the rest of the schedule. By the time the team achieved each successive milestone, the planning for the following milestone was complete.

During the implementation phase (9/3/96-10/7/96), a major problem was uncovered. The original design for a particular feature could not be implemented in the defined time. So, the replanning activity defined tasks for starting a partial system test in tandem with the completion of the feature. The milestone list now looked like this:

The difficult feature was not dropped, nor was the overall project schedule slipped. The system architect and feature designer spent much time redesigning and prototyping the feature. That (originally unplanned) work proceeded in parallel with the system testing. The tasks underneath the listed milestones changed around to accommodate the additional work on the feature.

Senior management and Messenger’s customers were astounded that the initial ship date was met. In addition, because everyone agreed to appropriate ship criteria, the product had very few customer-visible defects.

Summary

Iterative project planning is useful when the uncertainty is high, and the risk to shipping all requested features at the requested ship date is high. The iterative planning and scheduling technique provides:

1. A sense of urgency for the development team.
2. The ability to plan and adapt the critical path for the gradual unfolding of knowledge about the project.
3. A planned replanning effort. Most projects replan, this technique sets the expectations that the replanning will occur.
4. Use of the critical path to define priorities and motivate and inform the staff to the realities of the project.

Initially fixing the milestones but not the tasks allows for studiously and continuously shifting the critical path to make the most progress in a project. Then, even if the original dates are based on nothing but senior management’s wishes, the project manager can use a rational approach to plan and manage the project.

REFERENCES

DeMarco, Tom and Tim Lister. (1987). Peopleware, Productive Projects and Teams, Dorset House Publishing, New York.

Gilb, Tom and Dorothy Graham. (1993). Software Inspection, Addison-Wesley, Reading, MA.

Goldratt, Eli (1997). Critical Chain, The North River Press, Great Barrington, MA.

Maguire, Steve. (1994). Debugging the Development Process, Microsoft Press, Redmond, WA.

McConnell, Steve. (1996). Rapid Product Development, Taming Wild Software Schedules, Microsoft Press, Redmond, WA.

O’Connell, Fergus. (1996). How to Run Successful Projects II, the silver bullet, Prentice Hall, Englewood Cliffs, NJ.

Rothman, Johanna. (1997). Case Study: From “Chaos” to “Repeatable” in Four Months, Proceedings of Software Engineering Process Group 1997. Software Engineering Institute, Pittsburgh, PA.

Weinberg, Gerald M. (1994). Quality Software Management, Vol. 3: Congruent Action, Dorset House Publishing, New York.

Weinberg, Gerald M. (1997) Quality Software Management, Vol. 4: Anticipating Change, Dorset House Publishing, New York.

Time and time again in post-project lesson learned assessments, project teams list communication as one of the most needed areas for improvement. Many times on troubled projects, project team members feel that if the communication had been better, the project would have had a better outcome.

As a project manager, questions we should ask our self –
• Am I sending messages out clearly and concisely?
• Do the receivers of my message take the time to understand the message being sent and then take the time to repeat back to the sender their understanding?

I found the following video on YouTube that illustrates how the deliverables can be wrong due to lack of proper communication -

What is Change Management?
Change Management (CM) is an organized, systematic application of the knowledge, tools and resources. CM is responsible for developing and managing the execution of strategies and activities to support successful implementation of the project. Change Management strategies include gaining leadership support, ensuring that the business aligns organization, processes and systems, involving key constituents for understanding and acceptance; preparing, equipping and training the workforce to operate in their new roles; and aligning the workforce to support the initiative. As we can see, CM is a key for the SAP implementation, because the implementation will simplify and standardize business processes, will affect people, will change the way people conduct business and the way they get work done.

How Change Management Team Structured?
A typical Change Management team includes Site Coordinator, CM manager, CM Partner, Communication Specialist, Training Coordinator, Key Performance Indicator (KPI) Specialist, Security Primary Person of Responsible (PPR), and a couple of trainers. See the illustration below.

What are the Roles and Responsibilities of a CM team?
CM Manager is a full time role in global SAP implementation and should be on site. The role is responsible for leading CM team, communicating with Project Manager, Site Coordinator/CM partner about communication, training, KPI tracking and Security issues.

Site Coordinator can be a part-time role and should be on site. This role is a “go-to” person regarding site issues for core team*, extended team**, business leadership team and site management team. The role is responsible for communicating to all appropriate parties on overall project status, issues, successes, and barriers to keep the members engaged in the project.

CM Partner is from site and can be a part-time role. This role is responsible for supporting the CM Lead to execute the CM and training activities on site in local language. S/he is go-to person for extended team.
Training Coordinator is a part-time role from site. This role is accountable to site management for effective SAP training, which includes business processes and SAP basics, implementation in order for the overall SAP roll-out to be successful.

Trainers are usually the existing local Subject Matter Experts (SMEs). They will be most effective if they are very familiar with the existing business processes and also have a deep understanding of SAP. They are Extended Team members from the beginning of the project and will become the workgroup Super Users after go-live.

Security PPR is a shared resource and is responsible for giving SAP users adequate access to carry out the functions needed to do their job in SAP and make sure that “Sensitive” transaction codes (T-CODES) are comply with SOX control process

What are the Key Change Management Tasks?
As I mentioned earlier, CM is responsible for developing and managing the execution of strategies and activities to prepare the users to successfully utilize SAP in support of the business. To be specific, the following CM tasks need to carry out to support successful implementation of the project.

Organizational Impact Assessment
The goal of the Org Impact Assessment is to indentify personnel for critical job roles and ensure that the right workforce is adequately trained in business processes & SAP. The inputs are work streams/tracks (e.g. OTC), business processes (e.g. maintain pricing data), job functions (e.g. sales support), job roles and responsibilities (e.g. Create and change customer and/or material specific prices), name, training courses that this person needs to participate, etc. The output of the assessment is an assessment matrix. The matrix will link to staffing plan if applicable and later the training approach.

Communication Plan
The goal of the detailed communication plan is to let all employees know what is happening in the workplace. A detailed communication plan includes communication levels (E.g. Steering Committee), audience, purpose, events and messages, content developer, sender/approver, frequency, etc. It can help to gauge the effectiveness of efforts to communicate information throughout the organization and can ensure the messages about the importance of changes are getting through.

User Acceptance Event
After completion of internal team testing, one month prior to system go-live, the Core Team and Extended Team will work together to define test scenarios that are representative of key business processes. Extended Team members & selected Super Users on will participate in site. As you imagine, how CM team organize the event is critical for core team to conduct UAE successfully, especially when the UAE has to be virtually due to the time or/and budget constraints. CM manager and integration lead should work very closely to come up with a very detailed UAE Schedule which includes names/IDs of the integrated scenarios, time needed, scheduled dates, short and long descriptions, person who conduct scenario/s, etc. The plan needs to be communicated to participants 2-3 weeks in advance and all issues will be recorded & prioritized by CM team. Issues rated as “High” or “Very High” impact will be resolved before go-live.

End-user Training
The goal of training is to ensure user community is fully trained to operate (and understand) the SAP system for their specific job junction. The SAP training starts 3-4 weeks prior to system go-live. The Change Management team performs training assessment, comes up with detailed training plan and monitors the quality of the training. If SAP rollout is in an region that English is not users’ mother toque, the CM team will work with local needs to provide training in the appropriate language.
End-user training includes business process training to ensure that the end-users are educated on the critical business rules associated with the SAP transactions they will need to perform, and SAP basic training and SAP Delta training to ensure that the end-users are educated how to navigate through the critical transactions for their job roles and responsibilities, how to analyze data and reports generated from SAP and in problem-solving within SAP.

Business process training normally is provided by super user/s from business team; SAP basic and Delta training normally is provided by members from Core Team.

Key Performance Indicator (KPI) Tracking
KPI is a metric that assess the effectiveness of a process. The metric will be determined during final preparation in order to track that is the system working as designed, are the people using the system correctly or bypassing the system. KPI specialist from the CM team leads this activity. Each work stream has a set of KPIs that they have to monitor on an on-going basis. Examples of KPIs are financial (budget, variances), schedule, number of late deliveries, etc.

Lessons Learned
The goal of capturing lessons learned is to identify what went well and some of the major successes, to identify the challenges and future recommendations to prevent the challenge from happening in future projects or stages, and to identify the actions required based on information documented from team. During go-live, CM manager sends out the lessons learned template to track/team leads to solicit answers. Project manager will share the lessons learned at the project closeout meeting.

These are a very important set of CM activities that typically need to be done for a global SAP rollout. These activities need to be proactively managed, rather than reactively. If these activities are not done, the global project team will encounter many issues during the implementation, and will face high risk of failure.

Experience suggests that it is vital to form an effective Change Management team that is supported fully by the local GM and other directors. A local Leadership Buy-in event needs to be carried out 3-6 months prior to the project kick-off. A well defined roles and responsibilities need to be clearly communicated to site management team so the CM resources from site can be allocated and committed to project.

* Core Team: consists of project team members from IT Application team who are generally full time. Daily activities include system configuration and business process documentation.

** Extended Team: are subject matter experts (SMEs), they provide functional expertise for system design and implementation.

As you can see, global project teams have several unique characters and challenges, such as multi-functional, constantly evolving to meet business and resource constraints, matrix structured, culturally diverse and geographically distributed. These challenges resulted in that corporate culture is not very conductive for effective communication and cross-team learning. Many learning opportunities are missed and corporate have been paying high price for repeating similar mistakes. Thus, capturing and sharing lessons learned as must-to-have project management processes will reduce global project costs and increase customers and users’ satisfaction.

If you are responsible for global SAP rollout, here are some lessons learned that can benefit your team and your company.

Lessons Learned – Local Leadership Buy-in event
More often, global project team encounters issues like roles and responsibilities of extended team* are not well defined, local support team resources are not committed after project started, there is no go-to person on site to coordinate issues between site, business team and project team, etc. In order to get full support from the local leadership team, a project buy-in event needs to carry out by change management team 3-6 months prior to the project kick-off to help local leaders to understand that SAP implementation project is not only an IT implementation, but a business project as well; to help local leaders to understand the importance of aligning business to SAP; to communicate with local leaders clearly about organizational structure, business processes and business units that will be impacted by implementation, resource requirements, etc.

Lessons Learned – Decoding Email Messages
As many companies are moving their business to Asia, communicating effectively in a cross-cultural work environment can ensure companies’ international business success. Due to the language barriers and different vocabulary systems, core team and local users are having difficulty understanding and decoding email messages. As a result, misunderstanding often arises and issues do not get resolved on time, which affects activities schedule and eventually, affects the rollout schedule.

The recommendation is to conduct a Cross-Cultural Communication session during the Kick-off period to the local users and project team to recognize specific cultural differences, to aware of communication differences and to overcome or minimize the cultural communication barriers to high quality communication.

Lessons Learned – Local Site Coordinator
Global SAP ERP project team normally is referred to as “virtual team”. Team members are working on remote and scattered all over the world. For example, my team has about sixty members and they are located in Germany, Budapest, Mexico, US, Canada, Singapore, China. A lot of times, core team members do not know who to go to address local business-related activities and issues; users do not know who to go to bring up project and business-related issues; and local site management does not get the latest project status therefore unable to provide just-in-time support.

The recommendation is to nominate an experienced site coordinator onsite to act as a local go-to person for all SAP-related issues. The role is responsible for communicating to all appropriate parties on overall project status, issues, successes, and barriers to keep the members engaged in the project.

Lessons Learned – ERP concept and Global Business Process
For most international companies, global SAP implementation is to provide an ERP solution in support of constructing new production start-up in Asia. Most of users are new hires and they do not understand the ERP concept or the Global Template; they do not understand their roles and the associated business processes.

Recommendation is to conduct a Global Template Familiarization session to introduce the Global End-to-End Processes to the users. Afterwards, change management team should work with the local business to determine which processes are applicable to the site, and which ones need localization due to legal and language requirements. A process mapping exercise is highly recommended as well, where the to-be processes (Visio diagram with swim-lanes) are finalized and presented to the local management team. Upon their agreement, SAP roles are able locked, training courses for different SAP roles can be assigned.

Lessons Learned – To-be Process
Like I mentioned above, users are new and they do not have much of SAP and business process knowledge. It is unrealistic to expect users to grasp the to-be process fully.

Recommendation is to conduct a User Acceptance Test/Process Testing prior to go-live after end user Basic SAP and business process training. By now, the design has been tested by the Core Team, actual data has been loaded to the test environment, and Super Users have been trained in SAP and business concepts. The Super Users run through the integration test script. This milestone ensures the design works, the data load is accurate and complete, and the super users are trained properly. This key success step should be included in the project plan in order to give core team, business team and extended team good visibility.

Lessons Learned – Master Data & Data Validation
Another issue global SAP implementation team faces is that requesting for data validation took much longer than expected. Three steps that involved in master data. There are data collecting, data loading and data validation. Because not all colleagues from business have been told the data collection process, “how” to validate and the importance of validation, master data always came last minute and past the deadline.

The recommendation is that change management team to conduct workshops locally to explain the data collection and data validation process to business users; to help users understand the meaning of the fields to be validated; and to communicate roles and responsibilities surrounding master data collection and validation by specify who will do what by when. Further, requests for validation should be to a single individual, not a group. Project manager should segregate data load and data validation activities in work plan and ties back to articulating due dates for specific activities and responsibilities distribution list.

Lessons Learned – End User Training
According to normal SAP implementation methodology, change management team plans the training activities one month before system go-live. The training focuses on to-be processes.

Due to the cultural differences, people in Asia intent to nod a lot when instructor talking. It does mean they understand what instructor talking about, it only means that “I hear you”. They may not tell instructors if they really understand the process/SAP transactions or not. Core team members, for example, weren’t aware that some users didn’t take the basic SAP training until they started the delta training. This resulted in that user’s SAP and business process knowledge level may not attain the level expected and some users are unable to perform transactions in SAP, e.g. create STO to move raw materials from the US to Asia, near go-live.

The recommendation is to set up process to on board new staff. The process includes obtain the SAP ID, go through the SAP navigation training, the SAP functional module training, obtain the knowledge from Subject Matter Experts (SMEs), and go through the after-training test. The process should ensure the new users fully understand the process and can create the transactions in SAP independently. The standard training goes first, and in the support period, have a 2-3 week refresher training. People are more familiar with the process and know how SAP supports the process. They then start asking questions and we know their learning situation.

Sounded communication between core team and local extended team is very important factor for global SAP rollout. Including all team members in the email loop and plan the regular team update meetings can keep all parties on the same page on each project stage.

In summary, many leading companies use SAP ERP system as an essential infrastructure to provide integrated and standardized real time data to support their global operations. As they move their productions to Asia, they are facing very complicated issues and unique challenges due to national cultural differences and local requirements. Researches of the impact of different cultures on SAP ERP systems implementation in Asian region have not been taken widely yet. Any mistakes of implementation can cost company millions and millions of dollars. Therefore, these lessons we learned from real-time SAP rollouts will provide some guidance on global SAP ERP implementation in Asia.

ProjectMgr is a powerful web-based project management application that is user friendly and intuitive to use. Manage your projects, Collaborate, Share files and track time all on-line. No downloads, no installs, cancel anytime, hassle-free.