The success rate for IT project is
very low, for every organization managing multiple projects, there are
inevitably some projects that should be discontinued and the resources need to
be re-allocated to higher value purposes. However, that rarely happens in many
organizations for a myriad of reasons. Instead
of concentrating resources to complete major projects quickly, team members
worked inefficiently on several projects at once - often long after their
purpose no longer existed. Why is it so
difficult to kill failing projects?
Emotion: It takes quite a
sharp mind to foresee that a project is doomed to failure; and it also takes
strong willpower to detach oneself from the project and allow it to discontinue.
This is obviously the case when a person has to make the decision about their
own project, not decisions coming from up top. As both individuals and teams
tend to treat projects as either their baby, or an extension of themselves, so
they will either push a failing project along because of a strong emotional
attachment to it, or they see the failure of their project as their own
personal inadequacy. Furthermore, an organization’s attitude towards failure
determines the personal risk to individuals who say "I was wrong." If
the personal consequences of (probably) wasting organization resources are more
attractive than the personal consequences of admitting you were wrong, then the
failing projects won’t get killed smoothly.
Design criteria: A
well defined project brief or design criteria at the onset is one of the most
valuable tools for a team to reference throughout development process. Businesses
often see 'creep' in the parameters of a project, in an attempt to keep it from
failing. Or certain disciplines look to add value by including additional
features or opportunities, beyond the original scope. This is where the project
design criteria is crucial, for a project can either be killed or redefined -
often innovation comes from the failure of an alternate task.
Communication: A
kick-off meeting that includes teams members from all intended disciplines is
also critical, not only allowing everyone to understand the project intent and
their roles or responsibilities through a gated process, but also offering a
broader collection of disciplines with the ability to recognize if a project is
not reaching the intended goal. In
redesigning the process, it is good to have a kick-off meeting to the start of
every new product development. In this meeting, one of the standard work tasks
of the team was to define a set of kill conditions. Many of these were generic
across projects and some were specific to a given project. Teams were then
empowered to proceed through a stage - gate process informing management at the
gates rather than asking permission (proceed until halt). The team was also
empowered to eliminate the project if the termination conditions were reached. This
empowerment led to shorter lead-time in the development process and an earlier
end to projects that needed to be stopped. Terminating a project was now viewed
as an appropriate action rather than a failure.
Checklist or constant monitoring: At intervals appropriate to the project (milestones, time
intervals, etc.) you would have a checklist of these conditions to run through.
Or it was more the case of constant monitoring and when a condition was met,
the project was killed regardless of the stage. The second approach seems more
flexible, but more difficult to manage. This process was admittedly on a
smaller scale than an enterprise wide initiative, but a similar up front
definition of success and kill conditions could help an organization bring an
appropriate early end to failing projects.
Guidelines over rules. The pipeline is crowded with failing
projects that continued to absorb resources and clutter the pipeline. In the
end, you need to build a process that enables smart people to behave intelligently.
Set guidelines, not rigid rules for continuous evaluation, Another key is
that at the end of a project, you have a post mortem as part of the standard
work. The purpose is to review how effectively the process works and what the
team would change for the next project. In the case of a "killed"
project, the process review centers on: could you have done something
differently early on that would have facilitated success over kill? Could you
have made the kill decision sooner?, Can you change the project selection
criteria so that this project would not have been selected?
Either initiating business/IT initiatives or
eliminating projects takes strategic view and tacit methodology, it should not be
based on gut feeling only. Set the guideline to follow through; both think fast and slow, and well define the proper process in order to manage
the project portfolio at the most effective and efficient way.
0 comments:
Post a Comment