Large projects,
especially IT projects, act as fantastic revealers of a situation calling
for Strategic Simplification. IT Cortex is often called to assist a
company while a strategic project is well underway... and encountering
what can prudishly be called "issues".
IT Cortex recognizes
the specific nature of projects and
fully integrates that specificity into its methodology. Understanding
what makes projects so prone to failure is the first step in the process
of building the conditions toward their success.
Actually IT projects were an essential source of
inspiration to IT Cortex when it
designed its Strategic Simplification
methodology that enables companies to achieve true synergy between IT and
organization taking into account their business environment.
 | All projects have a lifecycle. They start
by pulling together resources - people, machines, material, capital - and end
when their predefined goal is reached - or .... when they are killed (as soon as they
appear to fall too short of their initial expectations). Contrary to
"regular" business,
the goal of a project is not to grow endlessly, but to deliver at some
point in time.
|
| Projects are mounted when an innovation is required -
otherwise their result could be bought right "off the shelf". Learning is
inherent to every project. At the outset the
project team has but a partial knowledge of the final solution and of the way to reach it.
Key investment decisions have nevertheless to be made before and
during the project lifecycle. Contrary to
business operation, not everything
can be predefined at the outset of a project.
|
| Projects require a significant amount of creativity and face therefore a
significant amount of uncertainty. Risk is inherent to every project. There is no
such thing as a risk free project. There exists risk free routines but this does not mean
that all endeavor rising above routine activity should be curtailed. Projects
- even after a bumpy ride - can turn out to be highly profitable investments.
Contrary
to experiments in "exact sciences", project outcomes are never guaranteed.
|
| Projects create a new value - distinct from the exploitation of that value. As
soon as this business value is created by the project team, it needs to be surrendered to
the operation team and/or the maintenance team. Delivering a project means primarily that those who need
it can use it and that it improves significantly their life. Contrary to regular business, no project ever gets a chance to
settle and get into "routine" mode.
|
| Projects have to deliver something that works and any result short of that is a
failure. No project is set up to build something that "could have
worked". No project is an attempt and should ever be considered as
such. They
would not be worth the hassle - and they
would not have been allowed to start in the first place - if they were geared toward such a petit objective. Contrary to a study,
a project has to deliver something "that runs".
|
| Project deliverables can not be cut in pieces in such a way that the pieces can be later assembled
without significant additional integration effort. In all projects, the whole is more than
the sum of the parts. There is always a highly non linear relationship between a project
size and the effort required to build the project solution. Moreover the timeframe of a
project can not be reduced by adding resources in proportion of the expected elapsed
time reduction. Contrary
to a mechanical process, a project requires a holistic approach.
|
| All projects are different. There does not exist two identical projects - even when they
are geared toward the same result, when they use the same tools and when they
take place in similar environments. Projects are brought to life by
people, animated by people with different backgrounds and are immersed
in a specific corporate culture. More
than everywhere else, the human factor is decisive in projects.
Ó IT
Cortex
|
