Monday, November 14, 2011

How to succeed in projects

If builders built buildings the way programmers write programs, then the first woodpecker to come along would destroy civilization
Gerald M. WeinbergWeinberg's Second Law
There maybe some truth to that but if we look at things from a 2000 ft cruise altitude, we may infer differently. In 1628, the grand warship Vasa launched for her maiden voyage. It started as a ceremonial trot around the Stockholm harbor but ended up in a disaster within ten minutes. The Vasa sank, taking many of those aboard with her. Loss of lives, money, reputation, and availability for war were a few of the consequences. Can we blame the shipbuilders as we blame the programmers – or is there a bigger problem, perhaps in the process used to build Vasa or create software programs or in project management method.
It is easy to point fingers but to find the root cause of a failure and use the lessons for the future is the right thing to do. Often, the difference between success and failure is spotting critical early warning signs that a project is in trouble. Rich Cook wrote an article for in which he described IT project failures as a fish left too long in the refrigerator, the failure becomes all too obvious. Once the fish starts to stink, the clean up of the fridge is done using baking soda. Only about 1/3 of the all projects end up being successful. So how do you convert project failures into project success – spot the stinky fish early. How do you do that? – add probes or sensors in your refrigerator that would trigger an alarm before the fish goes bad. Let us further examine what those sensors can be that will help us detect problems on a project. A lot of these are hard to measure objectively as some of these detection patterns come with experience.
Transparent Communication
One of the keys to detecting problems on a project is to have open communication. Managers don't have to wait for a status report meeting to find something is hung up. One key way to facilitate transparent communication is for managers to build trust with the project team members. If a project manager feels that the communication is not transparent, he or she should look at building trust and also keep track of the grapevine messages. Both inter-communications between management with the team and intra-communication between team members need to be healthy. It is the manager’s job to effectively manage both and resolve conflicts before they escalate. "Everyone is allergic to bad news." As a result, it's all too easy to develop a culture where bad news is slow to percolate upward – which deprives management of vital, if unpleasant, information. An environment where bad news is accepted will help build that trust for employees to be transparent. The earlier the bad news is received, the easier and less costly it is to fix the problem.
Project Management Methodologies
Project management methodologies used to run a project could also determine how quickly problems can be detected. Proponents of iterative development (agile project management) focuses on breaking projects into small chunks and delivering pieces of it fast for user feedback – this help to correct the course of the project as there are several milestones and the risky issues are handled first. On the other hand, waterfall model where the entire project proceeds step by step from analysis to final delivery can be hiding problems till no recovery is possible. More the milestones, better the tracking.
Lack of Commitment
Detecting lack of commitment or interest from project members can be another sign, which could lead to failure. One way to prevent that is to allow members to take ownership of the work they are doing. Also, the members should understand the goal and vision of the project and should be motivated by the outcome with tied incentives. Inherently, majority of software developers are introverts. Therefore, having a positive energy in the work environment helps. They are also creators so providing them flexibility in terms of work schedule can help them motivate. EA Sports is big on providing their employees with flexible work environment. Although working on a video game can be motivating enough, working to meet strict timelines can be de-motivating. So offering flexibility and additional on-campus services (e.g. gym, dry cleaning, car wash, mani-pedi, etc) helps to get them committed.
Project Management Tools
Moving on to more objective measures, there are tools, which can tell managers of the heartbeat of the project. Managers can use dashboard tools that provide visibility into a project at the click of a mouse. Tools like TargetProcess can help keep track of progress. It works similar to the tracking tools car dealers use when you take your car for servicing. The tool keeps track of every detail of the work that is supposed to done. It tracks who is working on it and the progress from one stage to another. One word of caution is that these tracking tools are as good as how well the employees input their progress. Therefore, proper governance is needed to maximize the use of these tools.
A way to hide problems on a project is for employees to work lots of overtime. In the Giga Safe case, the employees were working overtime with no proper strategy and the management was trying to meet the deadlines by making the teamwork work hard and not smart.
Another sign of a troubled project is when an enormous amount of resources are diverted to one project. From my personal experience, I have seen it happen a few times where several new team members were assigned to a “troubled” project. Most of the time this resulted in delays with old members training new ones and the quality of the end product suffered.
Schedule slips can trigger alerts that the project is in trouble. If there are too many reported software bugs that haven’t been fixed, may indicate a quality issue. Last but not least, scope creep or scope relaxation can also be indicators that the project is running into trouble.
All these project attributes can be tracked via a project management tool with active updates to management from the reporters. These project attributes are similar to the smelly fish and the tools are our sensors to detect the smell and notify us of a rotting fish – in this case a troubled project.

prepared by Deepak

21 Ways to Excel at Project Management

Project Smart provides a list of practices that would make project managers excel. This is the web version of their popular ebook in the same title. After explaining 21 factors that affect the performance of the PM, they put together a checklist that helps PMs to gauge where you are at.

It takes two to tango

In a recent blog post by Michael O'Brochta and Curt Finch at Project Smart, they refer the expression in the title to describe the relationship between a project management office (PMO) and an executive. As they elegantly put:

At the end of the day, success for either of them is dependent on the other. Executives depend on the work accomplished by project management offices for their own success, just as project management offices depend on executives for their success.

O'Brochta and Finch did a great job in discussing how healthy relationship between PMO and executives should be. Good that they are going to describe specific key performance indicators that a newly-established PMO can use to measure itself to ensure alignment with the needs of the organisation in their follow-up piece.

Thursday, November 10, 2011

Three common mistakes that flood IT Projects

Three common mistakes that flood IT Projects

I have been involved with IT for several years now. Since my high school years I've seen many IT initiatives fail miserably (i.e. disastrous implementation, horrible IT solutions, incomplete initiatives, etc.) and I've seen others be tremendous successes.

I recently came up with a blog posting by Ty Kiisel about common mistakes that plague IT projects. Seeing in retrospective, in one way or another, I can identify with those mistakes he mentions in the blog.

For example, he talks about the project manager setting up unrealistic deadlines for the team. The author suggests that while some projects require a hard deadline, most of them don’t. In my experience that holds true, or at least not you shouldn’t set up unrealistic deadlines especially when you are not expected to set them. I remember a time when one of our clients wanted to implement a new 3D scanning system in his manufacturing plant as part of a new quality management control system. The system consisted in a combination of cameras, sensors and software that took several pictures of a certain object and compared them against a previously defined “quality” product. The problem with this system is that it was the first time anybody in the team tried to “cluster” the cameras to shoot at the same time and tried to automate the camera’s functions via programming language. The client was very interested in the project because it would increase the speed of the quality control system without hiring more people. During the negotiations with the client, my team leader offered the finalized product into what we thought would be a very tight schedule if we knew the technology. When we found out what we were faced against, we discovered the deadline was totally unrealistic. Fortunately, the client was nice enough to accept a delay of over 4 times the expected delivery time. Lesson: never commit to a deadline (specially to an unrealistic one) just to impress people at the beginning, at the end you will impress them in the totally opposite way.

Kiisel also talks about risk not being managed and how ignoring it does not make it go away. I worked with a partner for a significant academic project as part of our thesis. We were building a vehicle traffic simulator in various computers at university. We had heard how a recent electric failure in one of the adjacent computer labs of the building had fried two of the research servers used in a thesis project for other group and how they lost nearly two years of research due to data damage. We were aware of the risk and we thought we should take precautionary measures in order to avoid data loss. We made backups of our data the next week and we forgot about the data loss case as the time went by. Nearly six months later, the same problem happened again but this time the fried computer was our server. If it hadn’t been for a backup made a week earlier by the recent automated backup system installed by the Research Department, we would have lost a tremendous amount of our time and data critical to our final project.

Finally, Kiisel also talks about the mistake of stakeholders not involved in the project. I found this several times in IT projects of third parties. For example, I remember how a supposedly high-tech emergency communication system installed in the school where I worked failed miserably. The US Department of State, through the US Embassy in my country, gave a substantial grant for the implementation of an emergency communication system installed in all school classrooms. The sponsor unilaterally decided to outsource the project to an external company that did the installation over a period of two months working during the weekends. The company never interviewed any of the stakeholders (faculty members, support staff, students, etc.) to gain insights about our needs, about stakeholders’ tech proficiency, among other factors. The result was an installed high-tech system that was so complicated to use that nobody could actually operate. The old system (walk and notify to the nearest secretary –even if she was in a different building-) was brought back and the new system was abandoned and remained installed as a symbol of failure. Personally, in this case I think there was more than just bad project management as I suspect the sponsor had some dubious interests in the company and technology used. This feeling became stronger when he was fired soon after the failed implementation of the project.


We have discussed some project failures so far in our course, which have been very telling, and even quite entertaining at times. I would like to share a brief chronicle of a highly successful IT project I have read about recently, IBM Watson.

Watson is a compute cluster built by the firm's DeepQA division. DeepQA's mandate is to perform research in the realm of artificial intelligence (AI) centring around human-like “open-domain” question answering. Open domain question answering is basically the phenomenon of a machine answering questions expressed in natural human language.

The 90 node, 2880 core, 80 teraFLOP Watson is among IBM's most impressive projects to date and in February, 2011, it beat the two top Jeopardy contestants of all time in a two game match demonstrating its capabilities.

This amazing feat was made possible, not only by brilliant engineers, architects, and powerful hardware, but highly organized and effective project managers as well. One of those project managers, Jim De Piante, sourced talent for practise competition against the supercomputer. Other key sub-projects included hardware delivery and staging, sample question development. Meanwhile, several other technical and non-technical project managers coordinated the efforts of at least nine other groups working in linguistics, systems, software development, game strategy (for playing Jeopardy), data linking, search, and more. Additionally, project managers had to coordinate all these complex sub-projects in order to complete the entire package that is Watson.

The budget was over three million dollars and the project was completed in approximately two years.

In order to ensure the project was completed on time, on specification, and on budget, project managers had to have a solid understanding of the ambitious project goals, resource constraints, software development, supercomputer hardware, human language, artificial intelligence, and working with a multicultural distributed team in four countries on a project some thought was impossible. It was an impressive feat indeed.


The importance of functional gap analysis to project success: A personal experience

I was recently involved in the preliminary stages of a IT project ,at  large organization,  that aimed to replace the central information sharing and document archiving system. The current system was a 10 plus year old mishmash of interdependent modules that were developed in house to meet the needs and demands of various stakeholders. The system no doubt needed to be replaced; the challenging question was what new system would provided the same level of functionality and integration with current business processes.

Despite the obvious challenge in finding an appropriate replacement system, upper management, due to financial pressures and politics, committed themselves to an off the shelf solution designed by an American vendor without conducting a  functional gap analysis in co-ordination with the major stakeholder.  The scope of the system replacement project was therefore limited to; getting major stakeholders to support the proposed change, working with the selected vendor to implement the system and pre-launch training.

The omitted functional gap analysis was a sure recipe for failure. The project planning stage, of which i was part, uncovered several intractable challenges the implementation project will be facing due to the omitted functional gap analysis. The standard answer to each new uncovered challenge quickly became "  well we are already committed to the new system". However, as the project planning progressed and more challenges were uncovered an unspoken consensus slowly emerged; the planned implementation will run into significant problems and the selected system will most likely not meet the needs and demands of its  users. In my estimation, this state of affairs were a direct consequence of the failure to conduct a proper functional gap analysis before selecting the replacement system.

I suspect that the situation I encountered is not uncommon. I imagine that economic pressures or the lure of the latest IT tool or fad, for example cloud computing,  frequently motivates managers to commit similar errors in judgement that ultimately jeopardizes project success.

In the interest of exploring my suspicion further, I will be happy to hear from other members of the class who had had similar project experience.

The top 10 Global Project Management Trends for 2011.

1) Leadership - Leadership skills will be the PM’s critical success factor. In current business environment leadership skills become more and more important

2) No Industry Will Be Spared from the War for PM Talent. Especially with growing number of projects going overseas, there is a growing need for experiences PMs.

3) Agile Project Management Not As Popular As Before - More organizations will realize that Agile does not suite all organizations

4) Competency Models Will Be Core to Managing Professional Development and Promotions for PMs - Hiring managers will be more sophisticated on selecting PMs. They will base their selections on comprehensive competency models.

5) Experiential Learning Will Be More the Norm than the Exception – Learning at work become more important. PM courses having hard time to keep up with the changes.

6) Informal Learning for PMs Will Gain Momentum – More learning will be acquired by using social learning technologies and approaches, such as wikis, blogs, videos, podcasts and other methods of communication.

7) Project Sponsorship Will Become an Area of Focus in South Asia - especially in India and Bangladesh, as organizations try to accelerate their structured approach to project management.

8) Outsourcing Will Remain a Risky Business – It means that PMs will have to focus more on the risk management and recognize the value of best practices in contract management.

9) PMs Will have to collaborate more with Change Management Experts – In a constantly changing environment PMs will drive the change, but they will need a reliable assistance.

10) The PMP® will continue to be the most popular project management credential in the world, but Will No Longer Be Enough – Companies worldwide will continue to support PMP®, but will value the proven experience and demonstrated competency beyond the certification itself.

The failure of the License Application Mitigation Project (LAMP):


The License Application Mitigation Project (LAMP) is one of the most famous IT project failures. This project was started in 1990 by the state of Washington. Its goal was to automate the state's vehicle registration and license renewal processes. Initially, the project was supposed to cost $16 million over five years. However, in 1992, the projected costs had climbed to $41.8 million, $51 million in 1993. It was lats estimated at $67,5 million in 1997. Finally, it became clear that the costs of installing the system were out of control. And, even if the project were completed, it would continue to be a huge and costly waste of money.

LAMP was turned off in 1997 after legislators calculated that this new system would cost six times as much to run every year as the system it was replacing.

It was estimated that nearly $40 million had been wasted in this project.

What reasons could lead to this failure?


The project’s failure stems from three main problems:

1) Management of the scope:

LAMP’s undertaking and expectations were very high. This was a very big concept which had very few intermediary deliverables. According to George Lindamood, the director of the state's IS department from 1993, "the project should have been broken down into smaller, measurable chunks, rather than spread out over several years.” Moreover, the requirements were constantly changed during the course of the project. For instance, after Lindamood left, legislators passed new licensing and registration laws that altered the project scope and caused further delays.

2) Split of the project between in-house developers and a private industry contractor:

By design, LAMP tasks were inexplicably divided between in-house developers and an external company. This led to communication problems and poor coordination. This is one of the reasons why LAMP faced so many delays.

3) Bad project management:

The chief issue about management was administrative meddling. From authorization to purchasing and quality assurance, LAMP was overseen by a mix of elected officials and political appointees. Not only these officials and politicians were not technically knowledgeable about the project, but LAMP was not a priority in their agenda. Experienced personnel should have been hired from private industry and empowered upfront, as opposed to putting political appointees in charge during the project.

The other management issue was that the organization didn’t want to hear that the project was a failure. The signs of failure for this project were evident from the first two years. Yet, no action or initiatives were taken to prevent this failure from happening. Project management should have identified and taken the following actions:

-Recognize and admit the symptoms of failures.

-Accurately identify what is going wrong in the project.

-Select suitable means of handling the situation, be it cancelling the project before costs become so huge.

What we can learn from this failure:

The chief lesson to learn from LAMP failure is that when a project is obviously doomed to failure, get out sooner rather than later!



Project Management Crisis? Hurry, But Do Nothing

Scope: Clearly defined scope and risk avoidance mechanism is also very important. Project scope approval by client and sponsor is required and any change in the scope should be taken as a change request.

The first part of the post is a replication of a post at . I will then offer my analysis in the second part.

Project Management Crisis? Hurry, But Do Nothing

We had a crisis. Another project had an emergency so we were losing a significant portion of our engineering staff to go work on that project. We had to act now!
Project management crisis hurry but do nothingWe were told to replan our project and to present a new project management tool schedule. No problem, we already had an alternate schedule ready. It was the schedule that had been rejected previously for the shorter one that was accepted. We adopted the previously rejected schedule and went on to deliver our product on time. One of our biggest customers told us that it was the first time in their memory that we had delivered a new product in the time frame we had promised it.
It was really fortunate we had a well developed schedule all ready to go. Actually, it was not fortunate, it was routine. Well, the part that was routine was that just about every project eventually had to respond to an emergency in another project trying to finish that caused newer projects to lose staff. The fortunate part was that we had tried to propose a schedule – one based upon objective data from just completed projects – but that schedule was rejected as too long. The humorous part was when we said we would use the previously rejected schedule, we also said it was ready to go and did not need to be updated. How could that be as we were months into the project? It was possible because that schedule already took into account the inevitable loss of staffing because it was based upon past actual project performance. (For more on performance based schedules see Get The Project Management Schedule Right!)
If we had used the initially rejected schedule then when the crisis occurred, and we lost staff, we would not have had a crisis. We could have just stayed on the same schedule and pressed on. Actually, we didn’t have a true crisis in any event. Since we didn’t truly need to replan, just use what was essentially the same schedule with adjusted milestones, there was little or no impact to any team. We just continued on course with the staff we had remaining.
The one big difference was that our project never had a crisis that then pulled staffing from the projects coming after ours. That probably helped explain why these later projects went on to receive recognition and awards for “flawless launches.” Prior to this, we never had any project anyone would have call a flawless product launch.
Objective and performance based planning can take the sting out of our typical crisis. When faced with an emergency we should be hearing ourselves say “no problem, we anticipated this possibility and have it covered.” This may ultimately help other projects to succeed as well.
MY Experience:
I have worked on projects that were delivered on time and also on projected that were not delivered on time or on budget. This has always been in my mind why some projects manage to meet the schedule while others don’t. This article made me to think and I came out with my own analysis. Some things that can create difference are

<!--[if !supportLists]-->1) <!--[endif]-->Planning & scheduling: The projects on which I have worked and which failed to meet the deadlines, were not because the team was not motivated or the requirements kept on changing but because the time required to complete the project (schedule) was flawed. The project estimates were given by a project lead who was working on another project and will not be working on this project. So the incentive to come up with the exact estimates was missing. So, who is estimating the project is very important. It is also important to involve the developers and testers in this process.
<!--[if !supportLists]-->2) <!--[endif]-->Communication: The client had no idea what was going on in the project and if there was any problem. The project managers were reluctant to talk to the client and explain the problems that the team was facing and when the client knew about it, it was too late. So communication is very important.
<!--[if !supportLists]-->3) <!--[endif]-->Planning the resources require: It is also very important to estimate the resources and skillset that are required to get the work done. In most of the projects, the main resources are moved to other new projects once the major functionalities are implemented. This means new resources getting added to the project, which leads to chaos.

Portfolio Project Management(PPM)

PPM is a strategy that allows organizations to align their IT and application development projects, resources, and initiatives to corporate business objectives by developing and monitoring measures that treat IT assets as financial assets -- and to run as a project-oriented business. PPM enables integrated management of pipeline, scope, time, resource, skills, cost, procurement, communication, reporting and forecasting, and risk management functions.
In essence, PPM allows us to manage a portfolio of projects much as you would manage a portfolio of diverse investments, such as stocks, bonds, real estate, and so forth. By maintaining a balanced portfolio, you can reduce the risks of individual projects and produce an overall higher rate of return. PPM allows executives and managers to proactively monitor their project portfolios for alignment with business objectives and planned costs and schedules. It also allows them to identify project risks and quickly address them.
Why do businesses need a PPM strategy? Let's look at some of the strongest reasons:
  • Limited IT budgets and resources. Most organizations need to improve the way they use their existing resources in order to maximize productivity. This applies to both people and tools.
  • Need for better IT governance (and data for compliance with Sarbanes Oxley Act ). Many IT organizations lack a consistent, accountable body for decision making. PPM provides a decision-making framework that helps ensure IT decisions are aligned with the overall business strategy; IT participates in setting business goals and directions, establishing standards, and prioritizing investments.
  • Need to improve project success rate. According to the latest Standish Group survey, executive support and clear business objectives are among the top ten success factors for application development projects. PPM includes approaches for achieving both of these requirements.
Table 1: Challenges for IT management roles 
  • Closer alignment of IT with business: With an easily digestible, holistic view of their entire project portfolio, executives and managers can more readily understand where IT dollars are being spent and which projects continue to be worthwhile.
  • Better IT governance: PPM helps managers monitor project progress in real time and provides detailed data to help satisfy Sarbanes Oxley Act compliance specifications.
  • Cost reductions and productivity increases: PPM helps managers identify redundancies and allocate resources appropriately; it enables them to make better IT staffing and outsourcing decisions, and to spot opportunities for asset reuse.
  • Business-based decision making: By viewing projects as they would view components of an investment portfolio, managers can make decisions based not only on projected costs, but also on anticipated risks and returns in relation to other projects/initiatives. This leads to improvements in customer service and greater client loyalty.
  • More predictable project outcomes: A PPM strategy bridges the gap between business managers and the practitioners who deliver the projects; it ensures consistent processes across projects and helps managers assess project status in real-time, predict project outcomes, and identify inter-project dependencies.
As Table 2 shows, the PPM strategy addresses four main aspects of IT management associated with specific activities and functions. The table also details automated support for these activities and functions.
Table 2: The PPM solution framework
Governance relates to the most important questions for software development and IT managers: "Are we working on the right things, and are we building the right system?" If their teams don't get this right, nothing else matters. A project might be successful from a schedule, budget, or scope perspective, but if it fails to meet business objectives, it fails overall. Efforts to align business and IT objectives are often thwarted by governance issues, such as:
  • Project teams use different vocabularies.
  • Team members do not understand the business objectives.
  • Projects are not prioritized by ROI potential.
  • Software requirements are not traceable to business objectives.
To address these common causes of failure, a PPM strategy provides support for governance, including:
  • Method management: A consistent, repeatable process, providing the means for establishing a common vocabulary, instituting a framework for assessing project health, and prioritizing initiatives.
  • Idea/innovation management: Support for considering IT project requests in relation to other prospective and current projects (project pipeline management).
  • Portfolio management: Ways to align and prioritize proposed initiatives and projects.
Functionality that enables planning under a PPM strategy includes:
  • Program management: A holistic view of multiple projects and their inter-dependencies.
  • Project management: Support for planning and tracking schedules, establishing milestones and assigning tasks for individual projects, identifying project dependencies, completing Gantt charts and other reporting artifacts.
  • Resource management: Ways to plan, balance, and schedule resources for IT initiatives.
  • Time management: Means to allocate, track, and compare time spent on project activities.
  • Financial management: Help with establishing and managing IT budgets; means for capturing expenses and obtaining approvals.
To ensure that developers build systems correctly, a PPM strategy includes functionality for:
  • Business process modeling: Support for managers to discover, document, and specify current business processes with metrics, and specify new goals and requirements.
  • Requirements analysis: Means to analyze financials and prioritize projects according to potential business value, define and prioritize requirements, identify/prepare existing assets for reuse.
  • Design and construction: Functionality for rapid integration and/or application development, visual construction and programmatic code generation, unit testing and debugging.
  • Testing and deployment: Support for functional and load testing, and for managing testing requirements.
  • Change management: Configuration management and change management support to deploy and monitor the solution.
To verify a system's effectiveness, a PPM approach includes functionality for:
  • Maintenance and productivity monitoring: Support for testing and measuring system performance.
  • Business metrics collection: Means for collecting and analyzing post-deployment business results. PPM also helps you track metrics for component reuse.
  • Setup and monitoring of Service Level Agreements (SLA): Setup for specific IT service levels and metrics collection for response time, service availability, and other parameters.
"How to Run IT Like a Business." CIO Magazine, May 1, 2004.
"At Your Service," eweek, March 1, 2004.,1759,1542787,00.asp
"The Best Best Practices: CIO Research Reveals the Basic Building Blocks of IT as a Business." CIO Magazine, May 1, 2004.


Wednesday, November 9, 2011

The Blending of Traditional and Agile Project Management

Traditional project management involves very disciplined and deliberate planning and control methods. With this approach, distinct project life cycle phases are easily recognizable. Tasks are completed one after another in an orderly sequence, requiring a significant part of the project to be planned up front. For example, in a construction project, the team needs to determine requirements, design and plan for the entire building, and not just incremental components, in order to understand the full scope of the effort.

Traditional project management assumes that events affecting the project are predictable and that tools and activities are well understood. In addition, with traditional project management, once a phase is complete, it is assumed that it will not be revisited. The strengths of this approach are that it lays out the steps for development and stresses the importance of requirements. The limitations are that projects rarely follow the sequential flow, and clients usually find it difficult to completely state all requirements early in the project. This model is often viewed as a waterfall.

Today, business processes are more complex, interconnected, interdependent and interrelated than ever before. Additionally, they reject traditional organizational structures in order to create complex communities comprised of alliances with strategic suppliers, outsourcing vendors, networks of customers and partnerships with key political groups, regulatory entities, and even competitors. Through these alliances, organizations are able to address the pressures of unprecedented change, global competition, time-to-market compression, rapidly changing technologies and increasing complexity at every turn. Because of this multifaceted nature of businesses, projects that implement new business systems are also more complex.

However, huge cost and schedule overruns have been commonplace in the past. Looking at the numbers, the past project performance record is troubling:
􀀁 $80 -145 billion per year is spent on failed and cancelled projects (The Standish Group
International, Inc.)
􀀁 25% - 40% of all spending on projects is wasted as a result of re-work (Carnegie Mellon)
􀀁 50% are rolled back out of production (Gartner)
􀀁 40% of problems is found by end users.

The Agile Project Management Environment
Unlike traditional project management, which emerged from the construction, engineering and defense industries and dates back to the 1950s, APM was born in the twenty first century. In 2001, prominent software developers from both IT and software engineering domains, convened to arrived at a consensus on how the software development industry could produce better results. This meeting produced the Manifesto for Agile Software Development, which states that the “highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
APM development is conducted collaboratively, with a small co-located team. There is minimal documentation as the team relies almost exclusively on informal internal communication. Again, this differs from the traditional approach where a considerable amount of time is invested in planning and a significant amount of requirements documentation is produced.
Agile Management Components
There are several key elements that provide the basis for APM. It is important to note that these techniques can also be used in traditional software development methods to improve project performance. They are:
- Visual control - This is a “cards-on-the-wall” method of planning to assist a team in organizing the work of the project.
- Co-located high-performing teams. In Agile development, all the key team members are co-located, including the customer/end-user, preferably in a work room. This approach greatly increases the quality of coordination and communication.
- Test-driven development. In cases when the customer is having a difficult time articulating requirements, agile teams often use test-driven development. Using the same successful Agile project team mentioned above as an example, the test cases were often developed first, and then the team backed into the requirement.
- Adaptive control. Everyone on the team is constantly adapting, which may make some team members nervous, especially those that crave structure. Because of this dynamic environment, the project manager needs to be seen as a leader, not a taskmaster.
- Collaborative development. APM relies on collaboration among all team members to deliver the results, capture candid feedback and implement learning’s on the next iteration of the solution. This is one of the strengths of APM - constant feedback and improvement.
- Feature-driven development. This practice greatly reduces complexity, because it allows the team to focus on one feature and only one feature at a time. For example, one team is working on Feature #4 and that’s the team’s only focus. They don’t concern themselves about Features #1-3.
- Leadership and collaboration rather than command and control. “The principles of APM are timeless. If you look at APM, it links much more closely to leadership. It addresses a lot of the steps that facilitate leadership much more than traditional management.
- Move from C (cost) to R (revenue) focus. Features are prioritized based on value, such as increased revenue or market share. It’s the business analyst’s role to ensure the Agile project team is not investing too much into the development of the new solution.
- Lessons learned. After each cycle, the team holds a lessons learned session to determine what they can do better on the next iteration. As the team learns, it adapts how the members are working together to continuously improve team performance.


“The traditional project management approach,” Augustine reports, “is a linear approach where you try to get it all done at one time. You do a lot of very detailed planning at once upfront and then deliver it in what’s known as the ‘Big Bang’. That industrial age thinking has spilled over from software development to other projects as well.” This is the heart of the difference between Agile and traditional project management. The ‘Big Bang’ now comes from the greater flexibility and collaboration APM provides. “Just enough” planning is done up-front. As each increment of the system is built, the team gathers input and learns from customer feedback.

“At its heart, project management, whether you are doing traditional or Agile has very similar principles. It’s about doing a good job for the customer. It’s about leading a team. It’s about delivering measurable business results,” says Augustine. Many of these principles or practices can be implemented into most team-structured environments.
Incorporating Agile management techniques into projects fosters a focus on the benefits of each feature. In traditional project management, the teams strive to finish the project on time and under budget and often lose sight of the overall benefits the entire effort is intended to bring the organization. It’s important to remember the strategy the project is expected to advance as well as the total cost of ownership and not just the project costs.

Published in PM World Today - May 2007 (Vol. IX, Issue V)
By Kathleen B. Hass, PMP,
Project Management Practice Leader, Management Concepts