logo
Your Ad Here

Knowledge - MAX

You have worked on various types of projects ranging from infrastructure to software.
How are infrastructure projects different from software projects?
First we must be clear on what we mean by "infrastructure". It could mean the hardware support for a
major software system. However, I take it to mean civil engineering constructed works such as roads,
rail, water supply and distribution, and so on. In this case, these types of project are differentiated by the
type of talent required for their accomplishment.
Infrastructure works require tradesmen with muscle and brawn, while software projects require
individuals with high intellectual capability. These two types of people need to be managed very
differently. In the first case, operatives respond better to "Tell me what to do and I'll do it" while in the
second, people respond better to "Tell me why I should do it and I'll try to figure out the best way."
Interestingly, experience shows that these approaches applied the other way round just don't work.
What are the critical factors that measure the success of capital projects?
Traditionally, capital works projects involve relatively large expenditures spread over relatively long
periods of construction time. Work once accomplished is tangible and is not so readily undone.
Consequently, sound planning, especially of the sequence and integration of the work elements, is
essential and, therefore, the focus is on efficiency, i.e. time and cost. Of course, the works, whatever
they may be, must perform satisfactorily. They must also be seen to be satisfactory from the public
users' perception and, more and more these days, environmentally sensitive. So that means quality and
integrity in the original design.
But, another interesting aspect is, who benefits from the capital project? Inevitably, there will be those
who do and those who don't, so the whole environment can become very politicized. The only way to
deal with this is a conscious public relations effort and, perhaps, this more than anything will shape the
degree of success of the project.
In the present scenario of frequent failure of software projects, can you put forward some
strategies that facilitates successful software projects?
This is a very interesting question. The software development industry is still very much in its infancy
and is searching for better ways to conduct such projects. A number of methodologies such as
PRINCE2® (UK) or the Rational Unified Process® (US) are being promoted. Certainly any
methodology is better than no methodology but I suspect that part of the problem is that such projects
are being judged, and managed according to the old construction project management paradigm.
Whereas a client can visualize a building or a road, it is much more difficult to visualize a software
"system" when what you see and feel is simply the user interface.
That means you must have some "product" to show the customer for review and decision-making and it
is not possible to plan the software works in entirety at the outset as in construction. What is necessary is
an "incremental" approach to development but, unfortunately, this flies in the face of traditional
procurement that requires fixed time and cost quotations from the outset. Until this dichotomy is
resolved, or both parties become "educated" to the inherent conflict and understand how to deal with it, I
believe that we shall continue to have serious software failures.
Scope and deliverables of software projects are changed frequently. This has severe
implications on the projects. How can a project manager minimize their impact on the
project?
This issue is really the flip side of the previous question. The project manager is often in a difficult
position because he or she may not be appointed to the project until after the most important decisions
have been made. That is, the procurement and contracting strategy to be adopted and the tools to be used
in developing the software product have already been determined. Moreover, many system
developments are not adequately "architected". That is to say, there is no one serving in the (traditional)
role of architect in the design of the comprehensive product that will produce a beautifully functional
whole that satisfies all the "-ilities" (Availability, Operability, Usability, Maintainability,
Constructability, Reliability, etc.)
Consequently, when these shortcomings are encountered, changes are requested or demanded, and not
unreasonably so. But changes are disruptive of progress and heighten the possibility of overlooking
software dependencies and consequent addition of bugs. The answer is for the project manager to be
well aware of such impending difficulties and be ready and willing to expend considerable effort in
"educating" management and the other stakeholders!
Project reviews and audits are important in project management. Can you share your
experiences about their contribution in the success of a project?
You are quite correct that project reviews and audits can be very important in project management,
especially if carried out expertly. They can be a good source of learning and improvement during the
course of the project resulting in improved outcomes, as well as a source of advantage if the findings are
properly archived for future projects. However, our personal experience is that such reviews and audits
are not popular as they are seen as criticism and not relevant to the real daily challenges at hand.
The project management process may already be too well established to be changed to any significant
degree during the course of the project. Alternatively, the project management staff may be "too busy"
to take on the added work load of providing the required information and respond to interviews, or to
make a serious attempt at changing the method of working. It appears that the most acceptable approach
is a post-project review when the players themselves have time to give serious thought to what happened
and be in a position to recommend ways of improvement on future projects.
You have valuable experiences in the field of project risk management. Can you share your
views on how an organization following project management should equip to cope with and
overcome project risks?
Project risk management is really not a difficult concept to understand and not a difficult process to
implement. At the earliest possible stage, gather the troops, hold a brain storming session on all the
things that typically and might go wrong, assess probability and impact of each item to establish a
ranking order, and find ways around for those of the highest order. Thereafter, keep an eye on what is
going on in the project's environment, look for "early warning" signs and be ready to plug in the
appropriate response with minimum delay.
The problem is that all this is "overhead" effort and is readily sacrificed to the god of "cost control".
Risk avoidance, like accident prevention programs are difficult to quantify in terms of return on
investment. This is especially true since projects are generally "unique" and have no established baseline
to be matched to. Add to that attempts by consultants to introduce sophisticated software analyses that
are really suited only to very large and dangerous projects, and it is not surprising that corporate
management tends to build resistance to the idea. In my view, the answer is to establish risk
management as part of the enterprise's overall standard project management philosophy, but keep it
very, very simple. There is always the opportunity to work at a more sophisticated level later, if need be.
Involvement of stakeholders is crucial for the success of the project. What strategies would
you suggest to project managers so that they can involve all the stakeholders in the various
stages of a project?
Involving stakeholders is very problematical. Who are they and what do they stand for, and what are
their respective interests? Depending on the size and nature of the project, determining this information
can be a serious challenge. Moreover, how do you get their interest before it is too late for the project
outcome to be significantly influenced? In other words people will participate if they really think they
can make a difference. However, both this process and the results of this process will cost time and
money and potentially take the project in a different direction. All of this could well be contrary to the
interests of the project's sponsor who is "footing the bill".
It can also be a challenge to the project manager who is left wondering "Who is in charge?" In my view,
not held by everyone of course, is that there should be lots of stakeholder involvement in the conceptual,
planning and design phases, and lots of involvement during the "finishing" phase when the product of
the project is being transferred to the "care, custody and control" of the operators and/or users. But
during the main execution phase of the project, keep the stakeholders informed of progress, but
otherwise keep them well out of the way of the production line!
What role do you envisage for future project managers in improving the discipline of
project management?
I believe that there is an important role for project managers, first to take the time to study the subject
and apply the knowledge to their projects, but secondly to work towards a consensus on what are the
best approaches to solving project problems under varying circumstances. At present there is much talk
amongst project management associations about "best practices". These are often assembled through
academic research questionnaires that only serve to determine what the majority of people presently do.
That can be useful information but does not in anyway imply what everyone ought to be doing!
But today, there are still serious gaps in both the "front end" and "back end" of project management
philosophy. The first is the best way to identify and formulate the most advantageous projects to start
with, while the second is how best to transfer the product of the project into its working environment at
the conclusion. These "best" practices can only come about through practical experience, and it is up to
project managers to capture and publicize that information in principle — confidentiality and copyright
of specific project information notwithstanding.
How important do you think on the job training is for the project managers and team
members? How can training needs be identified?
I do not believe that management or, for that matter, professional disciplines can be mastered entirely
through "book" learning. Practical experience is essential. However, to obtain the best advantage from
practical experience it is necessary to have some book learning first. By the same token, book learning is
far better absorbed after some practical experience. So, we have a "chicken and egg" situation here.
My ideal, therefore, is some elementary book learning first followed by practical experience followed by
more advanced project management learning, followed again by more senior exposure in the practical
world of project management. This is not at all easy to arrange in practice, and it may well be incumbent
on potential project managers to seek out their own experience. After all, commercial projects are not
the only source of experience. Projects launched by volunteer organizations and societies abound and,
from the all-important people perspective, are sometimes more difficult to manage.
Identifying training needs is a rather different issue. People who don't know what they don't know
cannot identify what they need to know. Therefore, there must be a commitment on the part of senior
management firstly to the program and project management disciplines, and secondly to improving the
capability of their personnel. Perhaps the best way of identifying the specifics is for an experienced
project management mentor to act as coach and advisor to management.