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. Weinberg, Weinberg'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 CIO.com 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.

http://www.cio.com/article/print/124309

http://www.targetprocess.com/

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.

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.

Watson

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.

Sources:

http://www-03.ibm.com/innovation/us/watson/research-team/

http://en.wikipedia.org/wiki/Watson_(computer)

http://www-03.ibm.com/innovation/us/watson/

http://www-03.ibm.com/innovation/us/watson/building-watson/index.html

http://www.research.ibm.com/deepqa/deepqa.shtml

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.

According to J. LeRoy Ward, PMP, PgMP, Executive Vice President, ESI.

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):

Background:

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?

Problems:

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!

Sources:

http://news.idg.no/cw/art.cfm?id=E38554CD-17A4-0F78-3158BDA5AC9294E6

http://www.inf.ed.ac.uk/teaching/courses/seoc2/2004_2005/slides/failures.pdf

http://www.cio.com.au/article/108289/managing_--_hell_back_/

http://infocommodity.blogspot.com/

Lucie BIENVENU

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 http://PMToolsThatWork.com/project-management-crisis-hurry-but-do-nothing/ . I will then offer my analysis in the second part.

Project Management Crisis? Hurry, But Do Nothing

[The original is at http://PMToolsThatWork.com/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!

We 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)

What is 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.

Business drivers for PPM

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 

Key benefits of PPM

• 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.

Aspects of IT management

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

 

Govern

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.

Plan

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.

Build

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.

Operate

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.

References:

"How to Run IT Like a Business." CIO Magazine, May 1, 2004. http://www.cio.com/archive/050104/howto.html

"At Your Service," eweek, March 1, 2004. http://www.eweek.com/article2/0,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.http://www.cio.com/archive/050104/best.html