A new project was approved and a 15 member team sit round
the table in the project kick off meeting with excitement and enthusiasm.
Business Analysts have put together the stories which Developers have started
developing. There were periodical project status reviews and there were issues
and risks discussed in these meetings and the project manager did well in
managing the issues and risks. There comes a message from stakeholders that all
work on the project be stopped with immediate effect.
That may be sounding familiar to every IT familiar as study
says that 37% of the IT projects are at the risk of failing. Another study
finds that 31% of the projects are cancelled before even hitting the finish
line. It really hurts the project team
members when a project is cancelled or shelved. But there could be reasons for
doing so and such decisions are taken when continuing with the project will
only increase the loss and would not bring in value for the sponsors. This is
where ‘fail fast’ will help as some times pulling the project down even earlier would save
a lot of efforts and money for the sponsors.
Let us see what can be done even before starting any work on
a project, so that the potential failure is spotted in the pre-project stage
itself so that the project is not allowed to start in the first place. When the
need for a project is felt, the executive management (sometimes called Project
Review Board) takes a look at it and reviews it and if it sees merit in it,
gives a go for the project. In some cases, by the time the Project Review Board
(PRB) sees the project proposal, considerable efforts would have already
incurred in the form of requirement gathering and analysis. The review by the
PRB members, when done well will bring out the ability to measure the risk
exposure and the RoI (Return on Investment) of the project, which in turn
influences the further decision. However, it is important here that the PRB
members shall be presented with adequate information that helps taking the
right decision. A well drafted checklist or template that captures all the
required information would help not to miss out the details and will help
reduce the projects failing down the road.
The project proposal template shall at a minimum capture the
following details, so that an informed decision is taken by the PRB.
Motivation:
The problem the project is expected to solve or a business
opportunity that the project will help the business to capitalize should be
stated well, so that the PRB members are able to appreciate the motivation
behind the project need. It would be appropriate to quantify the value /
benefit the solution would bring when implemented as intended. Some projects
may bring immediate benefits, whereas some may bring benefits in the longer
term, in which case, the same shall be called out explicitly. Similarly some
projects may bring in monetary benefits, while others may bring in intangible
value / benefits.
Estimated investment:
It may not make sense if the investment to be made for the
project is significantly higher, which may leave the value or benefit
negligible. Most projects get hit on account of cost overrun. The estimate
should be close to being accurate and use of a template will make sure that all
cost elements are considered. In some cases, a better estimation can be made
only after gathering requirements with sufficient details. It would be wise
that in such cases, the PRB may take a call to sponsor the initial efforts
alone and let the proposal be placed again for review with more accurate
estimation.
Constraints:
All projects will be constrained with various ifs and buts.
Each possible constraint should be identified and called out in the proposal
document. Each constraint will have one more associated risk items for which a
contingency plan and mitigation plan has to be put in place. Risk Management
practice has evolved in recent times and there are methods and techniques with
which the risks can be quantified (a factor of probability and impact) and the
overall risk exposure of the proposed project can be measured. This will help
the reviewers to take an informed decision whether this much risk is worth to
be taken for the value this project might give back.
Solution longevity and re-usability:
It would help if the expected life of the solution is
determined. Some of the solutions may have shorter life, but may offer the
re-usability with minor changes / enhancements. This will have to be determined
considering the longevity of the tools and technology that forms part of the
solution. Considerable number projects get cancelled as the sponsors gets to
know that the useful life of the solution is going to be short and that the
project may not be completed on time leading to further reduction in the
longevity.
The above are some of the key factors that influence the
decision on the project. There are many other factors which depending on the
nature and size of the project may have significant influence on the decision
making. For instance, security and compliance requirements could be a
significant risk, which the PRB needs to know of while taking the go decisions
on projects. Other factors that may find a place in the Proposal document
include, deployment infrastructure, post production maintenance aspects, choice
of technology, resource availability, etc.
On top of everything, the team that prepares the project
proposal document should have the expertise in the business domain, technology
used, estimation and related skill areas. Typically this will require a team of
architects of appropriate specialization to accomplish this.
References:
Here is an article by Jim Shore on how the 'fail fast' technique can help the developers write better code.
ReplyDelete