Part - - -
Why do projects need to be managed? In pairs discuss reasons other than timeliness and cost effectiveness why you think the projects should be managed. Keep the list to help you reflect on what you have learned as the unit progresses.
1.1 Project methodologies
Project methodologies (e.g. Prince2, waterfall, DMAIC methodology (an acronym for Define, Measure, Analyze, Improve and Control), critical path method (CPM), agile development, individual methodologies as required by the client)
The purpose of project management methodologies is to achieve a defined product (on time, under budget and to a stated quality standard) which may be a new network computer system or software installation. Project management is the means by which individuals and organisations ensure that the product is achieved within budget, on time and to the agreed quality. Structured methodologies follow the same stages as those identified in the waterfall model discussed in units 6 and 9. It is also important to recognize a project which needs managing. All projects have:
- A clearly defined goal or objective
- A deadline for completion
- The need for a combination of expertise experience and skills from different people groups or organisations.
- Clients may specify particular methodologies or you may be free to decide the most appropriate one for the project.
The waterfall methodology was originally used for the development of software. There are different versions with different numbers of stages. It will work in the same way whichever version you choose. You move down the stages rather like water cascading over the waterfall. All stages must be carried out in order and no stage can be omitted
The original waterfall methodology merely stated the stages to be undertaken with little guidance on how each stage should be carried out or monitored. As project became larger and more complex, more guidance was required on how to manage each stage. This resulted in the development of structured methodologies such as Prince2. These include detailed documentation and clearly defined processes which enable not only the development of the product but also the management of the development process.
Prince2 has seven stages and refers to products rather than deliverables:
1. Starting a project: a brief statement of why the project is required and what it will achieve. If approved, a more detailed brief is produced containing information on actions required necessary expertise resources etc.
2. Directing a project: the project board reviews the detailed brief, considering business need and likely success before deciding whether to appoint a project manager with agreed responsibilities.
3. Initiating a project: the project manager creates a project initiation documentation I described in LO2.1.
4. Controlling a stage: the project manager monitors and controls a particular stage to ensure that it remains on course, e.g. by approving the work to be undertaken, keeping the team informed of progress, noting any changes, reporting the status of the project board and taking any corrective actions if issues arise.
5. Management products delivery: this is the equivalent of the execution phase describing LO3.1. The products or deliverables are allocated across the team and produced to the agreed standard. Progress is monitored and the completed product is approved.
6. Product project closure follows the activities described in LO3.1
7. Planning: this is the equivalent of the planning phase described in LO2.2 as one of the techniques known as ' product-based planning' which requires creating:
a. A project product description: what exactly is the final product?
b. The product breakdown structure: the project outcome is broken down into smaller projects which are broken down into further outcomes until there is a hierarchical plan of how the project is created.
c. Product descriptions: each sub-product is described including its quality criteria.
d. Product flow diagram: the sequence that individual sub-products will be developed and how they relate to each other.
Figure 8.1: PRINCE2 structure
Figure 8.2: Spiral project management model
This is a prototyping methodology (unit 9 LO1) slightly adapted to produce an project management system which emphasises the importance of risk analysis. It has four phases:
1. Planning: the project requirements are gathered and recorded in the form of, for example a business requirement specification which focuses on what the business needs rather than how to achieve it and system requirements specification which focuses on how the business needs are to be achieved. It will identify as a minimum the data and functional requirements of the system that is being developed including security safety and quality constraints.
2. Risk analysis: risks to successful development of pointed and if appropriate alternative solutions identified. At the end of this phase of prototype is produced which takes account of the risks.
3. Engineering: the products developed and tested as to ensure that it meets at least some of the business needs to take account of the current risk analysis outcomes.
4. Evaluation: the customer evaluate the output and comments on the quality usefulness and other factors before the project team taking that of the findings starts the risk analysis phase again.
The spinal methodology is particularly useful when:
a. The project risks are high and the evaluation important
b. The users are unclear as to their needs
c. The speed of completion of the project is essential due to economic constraints
d. The project requirements are very complex and easy to prioritise.
The agile methodology argues that large projects can't be planned as the client is likely to change their objectives. No project can be wholly protected against change during development, because of these changing objectives and also due to unforeseen circumstances. This means that it does not make sense to set inflexible project development processes.
12 principles of agile development underpinned these arguments:
1. The highest property is to satisfy the customer early and continuous delivery of software.
2.Welcome changing requirements, even late in development. Agile processes harness change for the customers competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team's face-to-face conversation.
7. Working software is the primary measure of success.
8. Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace in definitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity - the art of maximising the amount of work not done - is essential.
11. The best architectures, requirements and designs emerge from self-organising teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
The "Agile" phases are:
Envision: the project scope and objectives are explored and the project team appointed. This is similar to the initiation phase in a structured method.
Speculate: similar to the planning phase. Risks identified, and organisational resources and needs recognised. The customer and project team work together to gather and analyse necessary data and information and estimate expected costs. Additionally, the initial steps of starting the development process are prepared.
Explore and adapt: these two phases can be run simultaneously throughout the project life-cycle. They include a range of activities:
a) Managing tasks and work load
b) Collaboration between the project team and the customer
c) Design and redesign of products
d) Decision-making about the next phase, design, redesign, adaptions to enable further improvement, et cetera.
e) Progress monitoring
f) Evaluation and reporting.
Close: Centre to the closure procedures of the structured method brackets see above).
Modified versions of the agile methodology such as scrum are described in unit 11 page 274. Each stage is reviewed and the results of the review fed back, to decide whether to repeat the stage or move on to another stage. The project manager role is shared between the team members.
Introduction (Six Sigma Principles)
Six Sigma (6σ) is a set of techniques and tools for process improvement. It was introduced by engineers Bill Smith & Mikel J Harry while working at Motorola in 1986. Jack Welch(CEO of General Electric between 1981 and 2001 who increased GE's worth by 4000% in that time) made it central to his business strategy at General Electric in 1995.
Six Sigma seeks to improve the quality of the output of a process by identifying and removing the causes of defects and minimizing variability in manufacturing and business processes. It uses a set of quality management methods, mainly empirical (measurable), statistical methods, and creates a special infrastructure of people within the organization who are experts in these methods. Each Six Sigma project carried out within an organization follows a defined sequence of steps and has specific value targets, for example: reduce process cycle time, reduce pollution, reduce costs, increase customer satisfaction, and increase profits.
The term Six Sigma (capitalized because it was written that way when registered as a Motorola trademark on December 28, 1993) originated from terminology associated with statistical modeling of manufacturing processes. The maturity of a manufacturing process can be described by a sigma rating indicating its yield or the percentage of defect-free products it creates. A six sigma process is one in which 99.99966% of all opportunities to produce some feature of a part are statistically expected to be free of defects (3.4 defective features per million opportunities). Motorola set a goal of "six sigma" for all of its manufacturing operations, and this goal became a by-word for the management and engineering practices used to achieve it.
The DMAIC Methodology Approach:
The main objective of this stage is to outline the borders of the project.
- Stakeholders agree on the parameters that will define the project
- Scope and budgetary items, as well as customer needs, are aligned with project goals
- Team development takes place as the project begins to take shape
The main objective is to collect data pertinent to the scope of the project.
- Leaders collect reliable baseline data to compare against future results
- Teams create a detailed map of all interrelated business processes to elucidate areas of possible performance enhancement
The main objective is to reveal the root cause of business inefficiencies.
- Analysis of data reveals areas where the implementation of change can provide the most effective results
- Groups discuss ways that the data underscores areas ripe for improvement
The main objective at the end of this stage is to complete a test run of a change that is to be widely implemented.
- Teams and stakeholders devise methods to address the process deficiencies uncovered during the data analysis process
- Groups finalize and test a change that is aimed at mitigating the ineffective process
- Improvements are ongoing and include feedback analysis and stakeholder participation
The objective of the last stage of the methodology is to develop metrics that help leaders monitor and document continued success.
- Six Sigma strategies are adaptive and on-going.
- Adjustments can be made and new changes may be implemented as a result of the completion of this first cycle of the process.
At the end of the cycle, additional processes are either addressed or the initial project is completed.
Six Sigma methodologies can be rolled out in a matter of months or over the course of years. From large international companies to mid-size firms, many high-profile companies have implemented Six Sigma strategies as a way of saving corporate dollars, increasing quality and leveraging the competitive edge.
The dynamic strategies of Six Sigma continue to evolve and are shaped by industry leaders who actively participate in professional organizations and other career development activities, such as continuing education. Professionals looking to pursue Six Sigma certification through the standard green belt, black belt, and master black belt progression can do so conveniently online without missing a day of work.
If you have experience in project management, you might have heard about the critical path method (CPM) — a project modeling technique developed by Morgan R. Walker and James E. Kelly in late 1950s. The critical path method (CPM) is a step-by-step project management technique for process planning that defines critical and non-critical tasks with the goal of preventing time-frame problems and process bottlenecks. The CPM is ideally suited to projects consisting of numerous activities that interact in a complex manner.
In applying the CPM, there are several steps that can be summarized as follows:
- Define the required tasks and put them down in an ordered (sequenced) list.
- Create a flowchart or other diagram showing each task in relation to the others.
- Identify the critical and non-critical relationships (paths) among tasks.
- Determine the expected completion or execution time for each task.
- Locate or devise alternatives (backups) for the most critical paths.
The origins of CPM:
The CPM was developed in the 1950s by DuPont, and was first used in missile-defense construction projects. Since that time, the CPM has been adapted to other fields including hardware and software product research and development. Various computer programs are available to help project managers use the CPM.
In small groups, identify a structured and an iterative project management methodology and compare:
- industry recognition of each methodology (i.e. accreditation)
- tools and techniques
- the stages of the methodology
- the risks of using the methodology.
Produce a presentation on your choices and findings to the wider group for discussion.
Development lifecycles have phases where activities take place. The names of these phases can differ, as can their content and scope. However, we shall briefly look at the key stages that all projects require.
This is the starting point of the project. It requires the project leader and the client or stakeholders to consider:
- Why do we need this project, why is it necessary?
- Who is it for?
- Stakeholders (Those with an interest in a project's development and who will be affected by its outcomes).
- Clients (those who will ultimately benefit from the project).
- Target audience (those who will use the product that is created).
- What do we want to achieve? What is our goal?
- Who is going to carry out the project?
- Who will need to be involved in the project (for example stakeholders and project and IT specialists)?
- Does the project have the necessary support from potential users, senior managers and so on?
More details in LO2
This phase takes the outline plans identified in the project initiation phase and converts them into a detailed project plan. This will be used as a reference document by the project manager and sponsor throughout the life of the project. It will be used to monitor and control the time, costs and quality (TQC triangle) of the project.
This is the longest and most complex phase of most projects. The deliverables (things that are to be made such as the product itself, the instructions on its use and troubleshooting information) are produced and the project manager and the project team use the project plan to identify the steps that need to be taken and monitor and control the pace of the development. The achievement of milestones against the projected timings is monitored using tools such as Gantt charts and the critical path method (CPM). In CPM all of the tasks of the project are identified on a chart to show what must be completed, how long it will take and which activities are dependent on each other. The critical path shows how long the project will take if everything runs to plan.
You are becoming used to seeing Gantt Charts such as the one below but ...
There is a connection between Gantt Charts and the Critical Path. The Gantt chart shown below ...
... shows the same information as this Critcal Path diagram.The critical path is the path that affects the total duration of the project. If one deadline is missed on this path then the project will be delayed.
The project manager will also monitor all elements of the project including costs, quality, risks and communications.
Evaluation or closure phase
This phase reviews the project in terms of:
- the quality of the deliverables
- the overall success of the project
- team performance
- the application of tools and techniques
- risks and issues and how they were resolved
- lessons learned which can improve future projects.
Communication is an essential skill for for project managers and team members. It invloves verbal and non-verbal methods of communication, the ability to listen and to adjust the communication to suit the audience. Examples include:
- The project manager setting the vision for the team - the purpose of the final outcomes and important details which the tean need to grasp quickly.
- Team members need to be able to communicate technical information to thers, adjusting their language for those with the same knowledge and expertise as well as those with different skill sets.
- The project manager needs to be able to communicate with sponsors, stakeholders and clients. This requires the ability to translate technical terms into language that these non-specialists can understand, so that they make correct decisions.
The types of communication can vary depending on the requirements but can include:
- Active communication, such as face-to-face meetings, presentations, webinars, tele- or video-conferenceing.
- Passive communication such as reports, emails, podcasts, webcasts, blogs or bulletin boards.
External and internal factors
While the project manager can try to develop a project plan which protects against disruption, some factors can cause problems. External factors are outside the control of the project manager or the sponsor, such as supplier bankruptcy or changes to laws or regulation which must be incorporated in the project plan. Internal factors affect those involved with the project such as the inability of employing staff with the requisite skills or the lack of accessibility to the appropriate resources such as equipment or facilities.
Several issues can cause conflict in the project team:
- Scheduling of team meetings. The team may be dispersed over significant distances and have multiple roles which can make attending meetings difficult. One solution is to set asside one day a week for team meetings from the start of the project. This would result in a 4 day week which is not particularly productive. Another alternative is video-conferencing via Skype as this is a software product.
- Project priorities. The team may be working on other projects or be part-time mabers of teh team. everyone must understand the priorities and if necessary, the project manager should adjust workloads to ensure that priorities are met.
- Resourcing issues and disagreements. These can include a lack of specialist staff. Accurate planning and scheduling of scarce resources can potentially resolve this issue.
- Access to specific project assets. Arguments can arise when two or more individuals wish to use the same equipment or software at the same time. The timeline of activities and deliverables could be used to identify the most deserving case. Ideally this should be scheduled to avoid clashes such as this.
- Project manager's management style. This must be appropriate for the team and the organisation ethos. This should be part of the project charter and be based on the experience and style of the Project Manager.
There can also be conflicts between the team and stakeholders, for example:
- Stakeholders have their own requirements and, where these requirements are very different, disgreements can lead to difficulties in gettingthe deliverables agreed or signed off. The TAURUS share dealing system is an example (link and link) of how a large number of stakeholders could not agree on the specification and the project was cancelled.
- Disagreements with supliers can occur over the quality of the supplied items or the timeliness of delivery.
The project manager must develop good interpersonal skills, demonstrating active listening and making compromises where this will not damage the project but will keep the team working.
Lack of management/leadership
Lack of management and leadership can cause conflict within the team, lack of progress, failure to resolve issues, poor project control and failure to maintain up-to-date records. It often arises because the project manager has limited experience and/or not enough training.
This can include a limited project plan or even know plan at all. The plan may lack clear timelines and milestones, all the activities required to create a deliverable may not be properly defined. Resources may not be linked to the activities and timeline and are not available when required.
The team need information and guidance to know what exactly they are expected to do and when they have to complete the task.
Legislation and regulation
At the start of the project the project manager should ensure that legislation such as the data protection act brackets 1998), the health and safety at work act brackets 1974 bracket and the equality act brackets 2010) will be met. The exact legislation and regulations depend upon the project, but the project team will need to comply. Issues can arise when the regulations and laws change or new legislation and regulatory requirements are brought into being during the project. This can result in changes to deliverables or team working practices which can require additional resources and changes of focus to comply.
Whatever methodology is used, documentation will be created. Table 8.1 provides an overview of types of documentation and their purpose.
|Document||Purpose||Why it is important?|
|Project brief / project mandate / (overview of project / scope / objectives)||It lays out the reason for the project and the objectives. that it must meet (e.g create an electronic customer order system which can process x orders per hour but will not include the order packing system or link to the accounts system.)||It briefly sets out the purpose of the project. All other documetation and activities flow from it.|
|Project initiation document (PID) (or project definitions document)||The top level planning document which provides , in a single place, all of the information required to start the project.||It identifies all those with an interest in the project (e.g. client, stakeholders). It also sets out clear aims and refined objectives, the required resources and deliverables.|
|Contract agreement from project sponsor / budget holder to start the project.||The agreement by the project sponsor anf budget holder (who may also be the project sponsor) that the project should go ahead.||It proves what was agreed, what would happen if the project was to stop early and who is financially liable for any overspends or overall failure.|
|Business case (project justification, costs versus benefits) or client acceptance form (to obtain agreement from the project sponsor or budget holder that the project is complete).||It provides a written explanation of why the project shold be carried out and provides a cost benefit analysis.||It provides the project manager with a guide to the design and management of the project together with ow it can be evaluated. This ensures that the project manager and the sponsor have an agreed view of what is required.|
|Work breakdown structure.||It converts the complex activities identified in the project plan into a set of separate tasks which each have some time element. As the tasks are clearly defined they can be assigned resources and funding which helps to manage the project budget.||It lets the project manager plan their work and manage the project budget moer effectively.|
|Project progress report (status updates while the project is in process).||It anables the project manager to have a clear understanding of the deliverables or tasks that have been completed, those that are in progress and those yet to be started. It may also include how issues are beaing dealt with.||It provides reassurance to the project manager, the project sponsoir and other stakeholders that progress is being made and that everything is moving smoothly and it will be completed om time. It also provides an opportunity for stakeholders to evaluate the project success this far and possibly make recommendations.|
|Project closure report (indication of outcomes).||It is produced at the completion stage or at an earlier point if the project was stopped following a phase review.||Every task required to close the project must be listed and described so that project closure is smooth and efficient.|
|Lessons learned report or survey.||It provides details of what went wrong or adjustments which had to be made during the lifetime of the project.||It enables those involved in future projects to learn how to avoid or mitigate similar issues leading to smoother project development and possible reduction in costs and timescales.|
Other types of documentation support the planning and control of the project. Table 8.2 outlines the most common documentation together with its purpose and relevance.
|Document||Purpose||Why it is important?|
|Project planner||A visual representation of the project tomelines and all activities that have to be completed (e.g a Gantt chart, or PERT chart or CPM or all three).||It alows stakeholders to quickly observe where activities are on track, delayed or not yet started. This allows for swift action to be taken when timing issue arise.|
|Risk register||A detailed record of all risks to the project and their significance.||It helps the project manager to monitor and manage risks and also identify, record and monitor new ones should they arise.|
|Issues register||A detailed record of issues and how they are being addressed.||It ensures that the project manager is aware of all issues, and to monitor and manage how they are addressed and wheter the approach is appropriate.|
|Lessons learned register||A detailed record of how problems were dealt with during the project's life and whether attempts to overcome them were successful, patially successful or had to be discarded.||It provides detailed evidence for teh "lessons learned report" created at the termination of the project to aid the smooth development of future projects.|
Below are four suggested assessment activities directly linked to the pass, merit and distinction criteria for LO1 to help with assignment preparation.
- P1: Describe the key stages in application development
- P2: Describe different project methodologies
- M1: Compare the features and benefits of different project methodologies
- D1: Evaluate the importance of each phase of the identified project life cycle
It should be possible to complete this as a single document if you wish or a set of three documents if that suits your style of writing better. Make use of the resources suggested in the left column and in the section that follows this.
For P1, the phases may be called different things, for example agile refers to "Envision" whereas spiral has a phases it calls "Review" but generally cover the same ground. A table that shows this may be of benefit here. Next describe in some detail the various phases stated by each methodology. The examiner suggests that there are four phases of the project life cycle i.e. initiation, planning, execution and evaluation. Then describe all of the different methodologies listed by the examiner (Project methodologies Prince2, waterfall, DMAIC methodology, CPM, agile development plus another one that you have found).
P2 is a simple description exercise, describe in some detail each of the suggested methodologies; Prince2, waterfall, DMAIC methodology (an acronym for Define, Measure, Analyze, Improve and Control), critical path method (CPM), and agile development. A sentence or two on the history of each as well as the phases and perceived benefits of each methodology.
For M1 the emphasis lies in the features and benefits of each different methodology. In the same way as Unit 6 briefly describe each methodology and then compare (identify similarities and differences) the features that you have discovered for each methodology as well as the benefits, in particular the circumstances where each methodology fits best.
D1 asks you to "evaluate the importance of each phase of the identified project life cycle" which is not easy. The simple answer would be to say that each phases is equally important. This clearly relates to the choice of methodology that you made for P1 and requires you to "make a qualitative judgement taking into account different factors and using available knowledge/experience/evidence". The image below shows a methodology (as 5 phases not 4 - control is continuous) and highlights areas that you may consider as important.
I would refer to the three elements of TCQ in my evaluation. For example, KPI stands for "Key Performance Indicator" which could be related to time, quality or cost, but the execution phase makes sure that the project is kept under budget, on schedule and built to the right quality standards. So how important is this phase? Can it be considered more important than any other phase?
The examiner suggests that learners could watch the following clips from which they make notes about the different project methodologies available. The tutors should encourage the learners to make notes of any features and benefits that they identify for each of the project methodologies.
Organisation: Project Management Videos
Resource Title: Why And How To Use PM Methodology - Web Link
Description: The above clip provides learners with an overview of the different project management methodologies.
Resource Title: 6 Project Management Methodologies - Web Link
Description: The above clip also provides the learners with a good overview of six different
methodologies and provides examples of the features and benefits of each.
Tutors could introduce the learners to the four phases of the project life cycle i.e. initiation, planning, execution and evaluation. The tutor could ask the learners to work in small groups and come up with a definition of what each of these phases means in relation to project management and its purpose within the project life cycle. Each group could present the outcomes of their research to the rest of the group and through a group discussion agree on a comprehensive explanation of the four phases.
The learners could be referred to the following websites as part of their research:
Organisation: Method 123
Resource Title: Project Management Life Cycle - Web Link
Description: The above website link will provide learners with an overview of the different phases of the project life cycle. They have referred to the final phase as closure but this is still part of the evaluation phase.
Resource Title: Fundamentals of Project Management - Web Link
Description: The above website provides a free online study programme for project management within the IT industry which learners may find useful throughout their study of this unit.
Organisation: Government of Canada
Resource Title: Project planning and evaluation - Web Link
Description: Although this particular website is linked to public safety in Canada, it does provide a good resource for learners to understand project management in general.
Project life cycle models are broken down into a number of distinct phases.
- closure or review
These can be further divided into the model preferred by the examination board.
You will already see that some of these documents have already been completed in your previous units.
There is a five phase project life cycle that emphasizes the management (monitoring and controlling) aspects of the project life cycle.
Additional resources that you may find useful:
- Project Management Life Cycle
- The Project Life Cycle (Phases)
- Project Management Principles
- Demystifying the 5 Phases of Project Management
- The Five Steps of The Project Management Life Cycle
- Project Management Life Cycle
- What is the Project Life Cycle ?
- What is the Project Life Cycle? The step-by-step guide for successful project delivery in today’s competitive economy.
- APM: Life cycle
- Class Notes on Software Development Process
- Why iterative software project management matters
- Top 12 Software Development Methodologies & its Advantages / Disadvantages
- SDLC Activities
- The Spiral Model Approach
- Boehm’s spiral model of the software process
- Project Lifecycle Models: How They Differ and When to Use Them
- Project phases
Understanding your audience
- How To Define Your Target Audience
- How to write a business case
- The Importance of the Business Case
- Writing a Business Case
- The Business Case
- Business case
- BUSINESS CASE: DEFINING A SPECIFIC BUSINESS NEED
- Business Case