Project Management Methodologies - Evaluation of Prince2 vs System Engineering - Essay Example

Project Management Methodologies Evaluation of Prince2 vs. System Engineering Name of Student: Student No: Date: Name of Supervisor: Introduction As a recent appointee in the role of Program Officer reporting to the Program Office Manager of an organisation based in Australia but with offices worldwide; I have been tasked with evaluating two project management methodologies namely PRINCE2 and Agile Project Management. The organisation provides a diversified portfolio of architectural design, construction and facilities management services maintains its own substantial IT infrastructure and is anticipating the need to manage significant organisational change over the coming decade. The Program Office has exclusively supported project management based on the PMBOK Guide, but is looking to support one additional approach to project management, to support future capability growth. In order to come to an understanding of which project management methodology works best, it is necessary to begin with a definition of methodology. This is known as a collection of tools, processes and methods that are aimed at achieving a goal. They give a checklist of important aspects of the project that need to be done and which activities need to be carried out to avoid missing these goals. Having a consistent system makes the operational processes simple and decreases the need for training. It also ensures that all personnel are following the same script. The aim of a project management methodology is to give guidelines on how to manage projects. The Project Management Body of Knowledge (PMBoK) is the go to system in project management methodology because the PMI project management certification process is popular. It is therefore used as the basis for many project management methodologies. It is the source of ‘best practises’ in project management and is supposed to apply to any project whatever SDLC was used. It is used mainly in the United States. One tool used to plan, schedule, and monitor a project progress is the project network. This network is created using data gathered for the WBS and graphic flow chart of the project job plan. This network illustrates how activities for the project will be done, including placing them in a logical sequence, demonstrating their interdependence and timetables for commencement and completion. The critical path is defined as the longest paths through the network. This network denotes the framework for the project information system which will be utilised by project managers to decide on matters pertaining to cost, performance and time (Larson and Gray, 2011). In order to evaluate the two methods comprehensively, they will be subdivided into phases and each phase will feature application areas pertinent to that phase including life cycle, processes, stakeholders’ role and responsibilities and documentation. There are various phases to a framework. The first is the Discovery Phase in which the initial stages are carried out. These constitute assigning an internal virtual team, initiating a client meeting in which business goals and requirements, project goals and project risks are defined. The existing system will then be analysed as well as skill sets and requirements. The project team will then review audit reports and produce a review recommendations discovery document (Stephenson, 2008). The next phase is the Design Phase in which project design will be reviewed with the internal team. The design will then be presented to the client who in this case is the Program Office Manager. An equipment and software list is then created and resource requirements created. This is followed by writing of a Statement of Works (SOW) and then a Proof of Concept (POC). A client sign off is then prepared for the Program Office Manager (Stephenson, 2008). The next phase is the Plan Phase in which we will create the Project Initiation Document (PID) and pilot test it. Once a review of the pilot test is done, the Bill of Materials (BOM) is modified accordingly and the PID finalised. Once this is done, it is time to plan documentation (Stephenson, 2008). Next is the implementation phase where the engineering resources are assembled, timescales are confirmed and resources are reserved. Knowledge transfer is then carried out and project meetings are done with the client. Installation is then deployed. This consists of having progress meetings, signing off at every stage, documenting activities, managing client updates, and problem solving. Finally, the project is completed (Stephenson, 2008). The last phase is the Acceptance phase where migration and acceptance occurs; the documentation is handed over to the client who then signs off on it (Stephenson, 2008) Development of a project network is an involved process that is expensive as well. It makes sense to develop one however because once implemented, they make life easier. This network is easily understood when developed graphically. This is because it has important data and insights on various issues. This includes formulating a schedule for labour and equipment, augments communication between managers and groups in order to increase efficiency in terms of cost, time and performance goals of the project. This is illustrated below: PRINCE2 PRINCE2 is a project management methodology created in 1989 for the British government. Non-governmental organisations (NGO) globally, have taken it on as the standard IT project management methodology. In Europe as well as the UK, it is still the most commonly used system and it is divided into eight high level processes. These processes are directing a project, planning, starting up a project, initiating a project, controlling stage, managing product delivery, managing stage boundaries and closing a project. Due to its flexibility, users simply customise the methodology to conform to their particular situation. This makes the process and its introduction to the firm simple. Quality management is defined by Yardley (2003) as the capacity to meet the objectives of the project. Three key elements are supported by this process. These are planning, assurance and control. Planning involves strategy to accomplish important standards such as ISO 9000. Assurance is the regular evaluation of performance while control ensures that the quality criteria for project deliverables are satisfied. Prince2 is distinguished from other project management methodologies by its emphasis on planning in all stages of the project’s life cycle. This is because it is an iterative process. This means that the organisation must demonstrate commitment and approval at appropriate levels. It has been shown that a lack of commitment in planning the different aspects of the project before inception is one of the most common reasons for failure (Court, 2006). There must be a framework provided by the methodology in order to prepare and maintain plans at a suitable stage of the lifecycle. It begins with the Project Mandate in which a direction for the project is set in terms of starting it up, appointing the Executive and the Project Manager, capturing lessons from previous projects and then designing and appointing the project management team. After this has been done an outline of the Business Case is prepared. A project approach is then selected and a Project Brief assembled. The initiation stage is then planned. Life Cycle The life cycle of the PRINCE2 project management consists of Starting Up the Project, which is then followed by Initiation. There are various Stage Boundaries to be managed and finally Closing a Project. Within the stage boundaries, there are various phases in which Work Packages are authorised, reviewed and received once completed. Each stage status is reviewed and issues and risks are captured, escalated and corrective action taken. Once one phase is completed, the next phase is planned and the Project Plan is updated as well as the Business Case. The end of a stage is reported and the next stage commences. The process is then repeated. Processes The director of the project is in charge of giving authorisation. He or she authorises each stage of the project life cycle, from its initiation to activation, each phase of the project and its closure. Before authorisation is given however, there must be a request put in for the relevant approvals at each phase. Once the project is approved, there are various strategies that have to be prepared. These are the Risk Management, Configuration Management, Quality Management and Communication Management strategies. This is followed by setting up of project controls, creation of the project plan and refinement of the business case. Once PID has been assembled, a work package is authorised, whose status is reviewed from time to time and once completed, and it is received by the Project Manager. An Exception Plan is prepared as well as a planned closure and premature closure. Handover of products is done and evaluation carried out and finally, a project closure is recommended. Stakeholders’ Roles and Responsibilities The stakeholders consist of the client, the Project Manager, the project management team, the Program Management Officer and the Project Board. The Project Board gives advice to the Project Manager when so requested. The Project Manager directs the project and gives authority for each phase to commence. They also give ad hoc direction to the project management team. The latter are in charge of the actual day to day activities that are involved in carrying out the project. The client signs off on various stages of the project and is the recipient of the final product. Documentation A large amount documentation is generated in the life cycle of the project. At the initial phase, a daily log, lessons log, outline of Business Case, project product description and project brief. Once the project is initiated, a project plan, detailed business case, risk register, configuration item records, issue register, quality register and benefits review plan are created. During the management of stage boundary phase, the PID, Config item records, risk register, issue register, quality register, project plan, business case and benefits review plan are updated. A stage plan, product description for the next stage, end stage report for the current stage, lessons report and exception plan is created. When closing a project, a follow-on action recommendation and lessons report are created. The PID, project plan, issue register, Config item records and benefits review plan are updated while the risk register, issue register, quality register, daily log and lessons log are closed. Applying PRINCE2® methodology gives the company more control because it will have resource and cost plans which are based on the need to keep the business viable. This last point is hard to accomplish because the business environment is always in flux and so there must be constant monitoring and control in order to achieve business goals. Since there is a formal structure within the organisation, this facilitates discipline on control procedures because the project members’ roles and responsibilities are clearly defined in the plans. As well as that, the reporting procedures are also well defined because members will have to report back to the project manager on their progress. The process of change is continuous and if the project manager does not expect change it does not bode well for the life of the project. It is necessary to manage this change in order to ensure that the client is satisfied, but there must be an established process in order to ensure efficiency and effectiveness (Court, 2006). Prince2 is acknowledged worldwide for the quality of its product. It is a standard project and adaptability. The purpose of projects is to consolidate resources, technology, skills and ideas in order to attain the goals of business and deliver the benefits. The purpose of good project management is to identify risks and manage them in a suitable way, as well as goals and advantages achieved within the budget, timetable and quality desired. Prince2 provides a framework that takes into account the wide variety of disciplines and activities that take place in a project with an enduring focus on the Business Case, which gives the underlying principle and business justification for the project. The business case is the driver for all the processes beginning with initial project set up to a successful conclusion (Office for Government Commerce, 1996). The characteristics of the PRINCE2 project are: A fixed and distinct life cycle. Definite and quantifiable business products. An equivalent set of activities which are aimed to attain the business products. A definite group of assets. Organisational structure with set out responsibilities for project management. PRINCE2 does not encompass all facets of project management. People management skills, leadership and detailed coverage of project management tools and techniques are excluded from it since they are well covered by other methods. Agile Project Management The concept of one size fits all in project management is obsolete in the eyes of many professionals and they acknowledge that this model does not completely meet their needs. This holds true especially for software and product developers who have vaguely defined end products and which are subject to evolution over time. This type of project is subject to flexibility and malleability in the way that it manages change. Thus Agile Project Management was incepted which relies on the incremental, iterative development cycle to bring a project to fruition (Larson and Gray, 2011). There are various Agile Methods and they are each distinctive in approach and implementation. They however display the same philosophy and nature that is iteration and ongoing feedback in order to refine and deliver software. The methods include Extreme Programming (XP), Scrum, Crystal Methods, Dynamic Systems Development Method (DSDM), Lean Development and Feature-Driven Development (FDD) (Agile Methodology, 2008). The ‘Product Owner’ works in tandem with the team in Scrum to discover and prioritise the functionality of the system which takes the form of ‘Product Backlog’. The latter is made up of features, non-functional requirements and bug fixes and whatever else needs to be accomplished to deliver a functional software system. The priorities are set by the Product Owner, and teams that are cross-functional estimate and endeavour to deliver ‘potentially shippable’ software increments during consecutive Sprints, which normally go for thirty days. Once the Product Backlog for the Sprint is committed, it cannot have functionalities added to it except by the team. Once the Sprint is delivered, an analysis and reprioritisation of the Product Backlog is done and should it be deemed necessary, a new set of functionality is chosen for the next Sprint (Palmer and Felsing, 2002). Lean Software Development is based on deliverance of Value to the customer by the team and with the Value Stream being made as efficient as possible. The main principles of lean include Eliminating Waste; Amplifying Learning; Deciding as Late as Possible; Delivering as Fast as Possible; Empowering the Team; Building Integrity In and Seeing the Whole (Popendieck & Popendieck, 2014). The original XP relies on the four values of simplicity, feedback, courage and communication and has twelve practises that support this. These are the Planning Game, Small Releases, Customer Acceptance Tests, Simple Design, Pair Programming, Test-Driven Development, Refactoring, Continuous Integration, Collective Code Ownership, Coding Standards, Metaphor and Sustainable Pace. Figure 1: Flow Chart for XP programming. Source: Wells, 2000. FDD is a short iteration process that is model driven. It starts with designing an overall model shape and then goes on with a succession of two week design by feature, build by feature iterations. These features consist of results that are small and ‘useful in the eyes of the client’. The rest of the process for development consists of delivering features using eight practises which are; Domain Object Modelling; Developing by Feature; Component Class Ownership; Feature Teams; Inspections; Configuration Management; Regular Builds and Visibility of Progress and Results. Proponents of FDD claim that it is more straightforward in scale than the others and more suitable for bigger teams. It diverges from other agile methods in that it illustrates particular, very short work phases which are to be separately completed per feature. These include Promote to Build, Domain Walkthrough, Code, Code Inspection, Design and Design Inspection (Highsmith, 2004). Life Cycle There are many opportunities to evaluate the direction a project is taking through its life cycle. This takes place because the work has a standard rhythm called sprints or iterations which produce a shippable increment of work at its conclusion. There is regular recurrence of truncated work cycles, in addition to the functional product. The agile concept ensures that every facet of developmental needs and design is reviewed at every stage of the life cycle. This is an inspect-and-adapt method to development which significantly decreases the development costs and time to market. A team work cycle is limited to two weeks and therefore stakeholders are able to recalibrate in order to ensure success (Palmer & Felsing, 2002). Processes The processes for different Agile Methods vary but consist of short cadences of work cycles at the end of which, a finished product results. As can be seen from the different methods above, this process varies according to the specific method involved. Stakeholders’ Roles and Responsibilities The stakeholders in this case consist of the project manager, their team, and the client. The Project Manager receives the assignment and promptly liaises with the client in a client meeting. This meeting is to clarify the goals of the project and set the parameters, choose which approach to utilise and develop requirements. First the PM and their team discuss scope and relationship of the project and then engage with the client with expedience. The PM and client agree on scope, timing and other important project parameters. The PM runs through the approach and gives them assignments to complete by a given date. A kick off date is set and agreement reached as to whom from the client’s end will be present at kick off. At the kick off, the application is demonstrated and the client is encouraged to ask questions and make comments in order to do a comprehensive development of requirements. These requirements make up the User Story which is constructed by the project manager and their team. The user story is what makes up the Product Backlog. The product backlog is used to commence development. The project team discusses the issues and gets started with development simultaneously. The team performs backlog grooming which comprises of a meeting where the team goes through the user stories and ensures that everyone understands what is required, the intricacy of the assignment is considered and estimates made of how much time and effort will be needed. The team then assigns each member a number which is known as the story point. Once this has been completed, then sprint planning takes place in which each member takes up a task from the product backlog (Larson and Gray, 2011). Documentation There are several reports produced in Agile. These include Burndown Charts, Cumulative Flow, Member Actuals, Defect Trending, Build Run Contents, Velocity Trends, Scope Change, Estimation Accuracy, Epic Bubble Chart, Test Status, Effort Trend, Epic Trend, Burnup Charts, Release Forecast, Member Load, Test Run Trend, Parking Lot, and Project Summary Trend. References Agile Methodology. (2008). Agile Methodology. Accessed online from http://agilemethodology.org/ Court, R. (2006). An Introduction to the PRINCE2 project methodology. CIMA. April. Highsmith, J. (2004). Agile Project Management: Creating Innovative Products. Pearson Education Inc. Boston, MA. Larson, E.W and Gray, C.F. (2011). Project Management; the Managerial Process. McGraw-Hill, 5th Edition. Office for Government Commerce. (1996). Managing Successful Projects with PRINCE2. Palmer, S.R. and Felsing, J.M. (2002). A Practical Guide to Feature Driven Development. Prentice Hall. Popendieck, M & Popendieck T. (2014). The Lean Mindset; ask the right questions. Addison-Wesley. Stephenson, C. (2008). Q Associates Project Methodology Framework. Q Associates, IT Solutions and Services. Wells, D. (2000). XP Flow Chart. Accessed online from http://www.extremeprogramming.org/map/project.html Yardley, D. (2003). Success IT Project Delivery: Learning the Lessons of Project Failure. Addison Wesley. Read More