Home About IUP Magazines Journals Books Archives
     
A Guided Tour | Recommend | Links | Subscriber Services | Feedback | Subscribe Online
 
Professional Banker Magazine:
Project Management : Sovereignty of PRINCE2 Methodology
:
:
:
:
:
:
:
:
:
 
 
 
 
 
 
 

Following a project methodology such as PRINCE2 helps project managers and those involved in organizing and delivering software projects, but methods such as PRINCE2 can become an almost insignificant factor in the face of risk, stakeholder management and personal politics. From the author's experience, methodologies such as PRINCE2 generally becomes a fetish, a procedure used with pathological rigidity for their own sake and not as a means to an end. Used in this way, PRINCE2 provides relief against anxiety and insulates the practitioner from risks and uncertainties of real engagement with people and problems. If we consider the inherent complexity of risk (i.e., time, cost and quality issues) associated with software project delivery, it is not too surprising that only one in eight projects will be delivered to their original time, cost and quality requirements.

 
 
 

It is generally believed that if a project follows PRINCE2, then it must be a success. PRINCE2 provides everything an IT project needs. It covers all the angles, ensures governance, appropriate project planning, risk management and clearly defined deliverables. However, speaking as Software Engineering practitioners, we believe that the above is false. Let us examine why?

First, we would question whether Project Management is the single most important aspect of an IT project to which all else is subordinate. In our view, an IT project requires three things of equal importance: a Project Plan, a Technical Solution and a Software Engineering Methodology. The Technical Solution (not the project plan) demonstrates that the objective of the project is viable and the Methodology (not the project plan) defines how the components of the solution are built and integrated.

Our experience of IT projects is that, first and foremost, there is a project plan. One of the activities of the project plan is to document the technical solution and another activity is to define the Methodology. But how can one have a project plan in the first place until the Technical Solution and Methodology are defined?

Would it make sense to have a project plan for building the new UK Wembley Stadium until the design is complete? And does it make sense to have a project plan for an IT system until the Methodology is defined? A methodology that is only implied or inferred from a sequence of activities in a project plan is a poor substitute for a well-defined Methodology that can be reviewed in its own right.

 
 
 

Projects & Profits Magazine, Project Management, Risk Management, Software Engineering Practitioners, Software Engineering Methodology, Technical Solutions, Software Development, IT System, Swiss Mountain Guide, Swiss-German Dialect, Project Planning.