Throughout your career in software development, you will likely be required to work on different styles of projects. The purpose of this topic is to provide you with the fundamentals of project management to assist you in the completion of your assessment for CS205. In this topic, we will look at:
- The types of project methodologies
- The lifecycle of a project
- Tools to manage the project, documentation and collaboration
- Expectations of project Reporting and documentation
In software development, various methodologies are utilized to manage and execute projects effectively. These methodologies provide structured approaches and frameworks for planning, organizing, and implementing I.T. projects.
Agile
Agile methodologies, including Scrum and Kanban, are iterative and incremental approaches that focus on adaptability and collaboration. Agile methodologies prioritize flexibility and responding to change over rigid planning. Projects are divided into short iterations or sprints, typically lasting a few weeks, with regular feedback and review cycles. The development team works in a cross-functional and self-organizing manner, delivering incremental product increments at the end of each iteration.
Agile methodologies are widely used in IT settings due to their adaptability, iterative approach, and focus on collaboration and customer satisfaction. Scrum, in particular, is a popular Agile framework that enables teams to deliver incremental value through short sprints.
When it is used:
Agile methodologies are suitable for projects with evolving requirements, high customer involvement, and a need for frequent feedback and adaptability.
Pros and Cons of Agile:
| Pros | Cons |
|---|---|
|
|
Waterfall
The Waterfall methodology follows a sequential, linear approach to project management. It involves dividing the project into distinct phases, such as requirements gathering, design, development, testing, deployment, and maintenance. Each phase has specific deliverables and milestones, and progress flows in a linear, cascading manner from one phase to the next.
Despite the rise of Agile, Waterfall methodology is still commonly used in IT projects, especially for projects with well-defined requirements and stable scopes. Waterfall's sequential nature and emphasis on documentation make it suitable for projects where upfront planning and predictability are crucial.
When it is used:
Waterfall is well-suited for projects with stable requirements, well-defined scope, and where changes are minimal or not anticipated.
Pros and Cons of Waterfall:
| Pros | Cons |
|---|---|
|
|
Lean
Lean methodology, derived from Lean manufacturing principles, focuses on maximizing value while minimizing waste. It emphasizes continuous improvement and efficiency in project management. Lean methodologies aim to identify and eliminate non-value-added activities, reduce delays, and optimize resource utilization. Lean tools such as value stream mapping, Kanban boards, and Kaizen are utilized to streamline processes and improve productivity.
When to use:
Lean is suitable for projects where efficiency, optimization, and waste reduction are critical, such as process improvement initiatives or optimization projects.
Pros and Cons
| Pros | Cons |
|---|---|
|
|
Spiral
The Spiral methodology is an iterative and risk-driven approach that combines elements of waterfall and prototyping. It involves multiple iterations, each consisting of requirements analysis, design, development, and testing. The project progresses through the spiral in a controlled manner, with a focus on risk identification and mitigation. Each iteration builds upon the previous one, incorporating feedback and refining the solution.
When to use:
The Spiral methodology is useful for projects with complex requirements, high risks, and a need for ongoing risk management and stakeholder involvement.
Pros and Cons
| Pros | Cons |
|---|---|
|
|
DevOps
DevOps is a methodology that combines software development (Dev) and IT operations (Ops) to create a collaborative and efficient project lifecycle. DevOps emphasizes automation, continuous integration, continuous delivery, and close collaboration between development, operations, and quality assurance teams. It aims to streamline the software development process, ensuring faster and more reliable deployment of applications. DevOps methodologies often involve the use of tools and practices like version control, automated testing, infrastructure as code, and continuous monitoring.
When to use:
DevOps is suitable for projects that require frequent releases, high quality, and close coordination between development and operations teams.
Pros and Cons
| Pros | Cons |
|---|---|
|
|
PRINCE2 (Projects in Controlled Environments)
PRINCE2 is a structured project management methodology widely used in IT and other industries. It provides a comprehensive framework with defined processes, roles, and responsibilities for effective project management. PRINCE2 divides the project into stages, with clear milestones, deliverables, and control mechanisms. It emphasizes the business case, risk management, and continuous project evaluation.
When to use:
PRINCE2 is suitable for projects with a defined structure, rigorous governance, and a focus on project controls and documentation.
Pros and Cons
| Pros | Cons |
|---|---|
|
|
Summary
These are just a few examples of project methodologies utilized in IT. Each methodology has its strengths and is suited for different project scenarios and requirements. It's important to consider the specific needs of your project, such as the project scope, complexity, flexibility, customer involvement, and risks, to select the most appropriate methodology. Additionally, hybrid approaches that combine elements of different methodologies can also be utilized to tailor the project management approach to specific project needs.
- The Moscow Technique by Tech Target - an online article about using the Moscow method in project management.
- The Top 10 Project Management Methodologies by Project Manager.
A project is a temporary activity designed to deliver a defined outcome. It has a defined:
- Beginning and end
- Scope and resources
- Goal, or goals, outside business as usual operations.
A project is a unique activity, which is often delivered by a team that doesn’t usually work together. A project is usually deemed successful if it achieves its objectives within the time, cost and quality constraints agreed upon in the plan. Developing a new piece of software to improve your business processes is a type of project.
And all projects must be managed to deliver their defined results on time and on budget; integrated into the business-as-usual components of the organisation.
Overview
Projects vary in size and complexity. All projects can be mapped to the following generic lifecycle:
Project lifecycle
- Starting the project
- Organising the project
- Carrying out the work
- Closing the project
Alongside the stages in the lifecycle, there are three processes that run throughout the project and are essential components to its successful delivery.
These are:
- Engagement with your stakeholders
- Identification and management of the project risks and processes to
- Strategically monitor and review the organisational environment and its impact on the project.
The image below outlines the high-level deliverables, activities and staffing across a generic project lifecycle structure. Each stage in the lifecycle has a gate, defined deliverables that must be completed before you can move on to the next stage.
Let’s take a few minutes to discuss this before we get into the specifics:
| Identify the need |
Opportunity for change is identified with the decision to launch a project.
|
|---|---|
| Scope the project |
Prepare the project charter.
|
| Plan & Design the project |
Prepare the Project Plan.
|
| Implement the project |
Implement the project plan.
|
| Handover the project |
|
| Evaluate the outcomes |
Deliver project to Sponsor & critical key stakeholders
|
Before a project can commence, you need to develop a document that provides the organisation with a clear reason for needing the project, and high-level detail on the scope of the work to be undertaken. This is usually developed through a business case or similar project initiation template.
Your project initiation document needs to provide decision-makers with a reason for supporting and funding your project. It should clarify what the project is about and what it will deliver to the organisation. You could commence this process by answering the following high-level questions:
- What is the driving need of the project? What problem/issue is it solving; or opportunity it is taking advantage of; or what legislative/regulatory need is it meeting?
- What does the project aim to achieve?
- What activities would achieve this desired outcome?
- Who does the project affect? Who are the other stakeholders?
- What is the scope of the activity of the project?
- What is not included in the scope of this project?
- What resources would be required to complete these activities?
- What would the anticipated timeframe be to complete the activities?
Organisations use some form of charter, project initiation document, scope or brief to define and capture agreement on the scope and governance of their project. We’re going to refer to this as defining your scope.
Governance requirements
Project governance is an oversight function that is aligned with the organisation’s governance model and that encompasses the project lifecycle. A project governance framework provides the project manager and team with structure, processes, decision-making models and tools for managing the project while supporting and controlling the project for successful delivery.
These structures provide a comprehensive, consistent method of controlling the project and ensuring its success by defining and documenting and communicating reliable, repeatable project practices. It includes a framework for making project decisions and defines roles, responsibilities, and accountabilities for the success of the project. It also determines the effectiveness of the project manager. A project’s governance is defined by and fits within the larger context of the portfolio, program, or organisation sponsoring it but is separate from organisational governance.
Project governance involves stakeholders as well as documented policies, procedures, standards, responsibilities and authorities. Examples of the elements of a project governance framework include:
- project successes and deliverable acceptance criteria
- process to identify, escalate, and resolve issues that arise during the project
- relationship among the project team, organisational groups, and external stakeholders
- project organisation chart that identifies project roles
- processes and procedures for the communication of information
- project decision-making processes
- process for project stage/phase gate reviews (before proceeding to the next stage/phase)
- process for review and approval for changes to budget, scope, quality, and schedule which are beyond the authority of the project manager
- process to align internal stakeholders with project process requirements.
While project governance is the framework in which the project team performs, the team is still responsible for planning, implementing, controlling and closing the project. The project governance approach should be described in the project management plan.
Project governance accountabilities
Many projects run into trouble because they do not have clear accountabilities. A RACI matrix is a great way to define your governance accountabilities up front.
RACI matrix
A RACI (Responsible, Accountable, Consulted, Informed) matrix describes how the project roles are involved in the delivery of tasks, activities and deliverables.
- Responsible
- The role(s) who will do the work to achieve the task
- Accountable
- The role with ultimate responsibility for the completion of the task or deliverable. There can only be one accountable person per task or deliverable
- Support
- Depending on the project, you could also include Support and create a RASCI matrix
- Consulted
- People whose opinions are sought are usually experts. (Two-way communication)
- Informed
- The people who need to be kept up-to-date on the progress or completion of the task or deliverable. (One-way communication).
A template and more information are provided in
Defining your scope
There is no formal list of content for a project charter or other scoping document. Your organisation might have a template, or it will be up to you to create one. The following template includes the common requirements.
Knowing what you need to complete the scope will help you identify the work you need to conduct.
Your Project Scope effectively becomes the executive summary of your project plan and the contract for what you will deliver in your project. It needs to contain enough detail to be meaningful, but it is not the project plan. It is the document that is usually developed to seek authorisation to continue with your project, at least to the Planning stage.
The following are usually developed in collaboration with key stakeholders and subject matter experts – who will also be involved in the planning process.
| Project Name | What you plan on calling the project within the organisation | ||
|---|---|---|---|
| Project Sponsor | The delegate who will own and support the project | ||
| Project Manager | You | ||
| Project Governance | A simple statement about the governance structure – particularly noting any Steering Committees or other bodies that have a role in oversight or decision-making. | ||
| Project Description | A brief description of the project. Don’t get too caught up in the details here, it’s often best to explain it in simple words about the problem it is solving or the opportunity it is taking. You could include the vision statement here too. | ||
| Project Outcomes | See note below on Outcomes – these are the long-term benefits that the project will deliver to the organisation. | ||
| Alignment to Organisational Goals and other Projects | Where does this fit into the goals of your Strategic Plan? Does it align with the delivery or outcomes of other projects? Include them here. | ||
| Project Goals and Objectives | See note below on Goals/Objectives. Remember SMART. | ||
| Resources and Budget | Since you have not completed actual tenders or procurement plans, this is the best guess for the information you have right now – but it should be altered after the final budget and resources have been approved. Include a budget for external expenditures, people resources, equipment and other physical resources required. |
||
| Deliverables | A simple list of what you will be delivering as part of the project. This is not your full work breakdown structure, just the high-level deliverables. Remember to think broadly, if you are delivering a new IT system are you also delivering training and manuals? |
||
| Inclusions | What is included in the scope of the project? Think about whether it will cover the entire organisation or only select units. Consider the deliverables above and what you might want to be explicit about. | ||
| Exclusions | This is extremely important to define early; what is not in your scope? This will help you avoid scope creep. Even if you think it is obvious that you aren’t doing something, spell it out for everyone else. | ||
| Assumptions | What have you assumed will be available or will be happening to make this project work? This could include simple things like, The finance unit will provide the team with an SME for the duration of the project. If you are relying on another part of the business to complete a project or activity, then include it here as well. | ||
| Constraints | What are your known constraints within this scope? Capture them here so people know you have taken certain issues into consideration. This could include the availability of people, peak season timings, deconflicting projects etc. | ||
| Key Risks | You are only including what you see as the major risks for the successful delivery of the project. You might have already identified them in the assumptions and constraints, but spell the key ones out here – you do not need mitigation strategies in the Scoping document. | ||
| Key Stakeholders | Who are your Key stakeholders? Who is going to be primarily affected by the project? Who needs to be involved in any aspect of the delivery? Who do you require support from? List out your Key Stakeholders here, not the analysis of them. | ||
| Responsibilities Reporting, accountability and limit of authority |
What are your responsibilities as the Project Manager? Include reporting requirements, your personal responsibilities and what you need to seek approval for. | ||
| Proposed Start Date | Proposed Completion Date | ||
| Signature of Project Manager | Date | ||
| Signature of Sponsor/Manager | Date | ||
Benefits and objectives
Importantly, every project needs a well-defined purpose and set of objectives. These statements not only provide detail to decision-makers, but they will become a fundamental aspect of communication and a broader understanding of the project’s scope.
The purpose of the project is answer to the question, “What is it aiming to achieve?”. This is a very broad statement but think about what your project is uniquely attempting to deliver to the organisation. Most often, projects are developed to solve a problem within the organisation, which makes their purpose easier to define. Does the project:
- Improve the efficiency of a business process?
- Remove redundant and unreliable systems?
- Allow the organisation to better accommodate its workforce?
- Allow the organisation to meet legislative requirements?
Framing it as the problem you are solving for the organisation is often a great way to start.
You need to understand the difference between these terms:
- Outcome (or Benefits) – this is what the business, staff, or customers gain from the project
- Objective (or Goal) – this is what you are aiming to achieve and should be written SMART.
Outcomes
The outcomes are usually written as To statements:
- “To promote…”
- “To provide…”
- “To improve…”.
For example:
“To provide clarity around procurement” or “To improve the safety of warehouse operations”.
Importantly, these are high-level statements that express the benefits to the organisation. You must have at least one Objective for each Outcome, so you can measure your success.
Objectives
As part of your project initiation and definition, you will develop a range of objectives or goals. It is important that these statements are clear and well-defined. This will help guarantee everyone is working towards a common end state and defines how the success of the project will be measured.
One way of developing these statements is the use of the SMART goal framework:
S.M.A.R.T. goals
| Specific | Make the desired goal as specific as possible, and avoid generalisations. |
| Measurable | How you will measure it- what can you measure? Is it indicative of project intent? |
| Achievable | Consider the activities in the project and whether it is doable. |
| Relevant | Does this goal align with the purpose of the project? |
| Time-bound | The date you will achieve the goal. |
An example of how this might look:
- unSMART goal
- Provide the organisation with state-of-the-art meeting rooms.
- SMART goal
- In the new office, we will provide five meeting rooms that will support the majority of meeting requirements for the organisation, with integrated AV systems – as outlined in consultation with key stakeholders and IT.
Other definitions
Assumptions
According to PMBOK, an assumption is A factor in the planning process that is considered to be true, real or certain often without any proof or demonstration. There are things that, through experience or known processes, you can presume will be true for your project.
Importantly, all project assumptions are potential risks and need to be stated clearly for everyone involved in the project.
Constraints
According to PMBOK, a constraint is A limiting factor that affects the execution of a project, program, portfolio or process. They might be imposed by stakeholders, the environment or other organisational factors.
Importantly, constraints need to be considered in the planning and delivery of the project and can often compete against each other. For example, a constraint in available resources, which requires you to hire an industry specialist, could directly conflict with budgetary constraints. The project manager is required to balance and deconflict these matters.
Deliverables
A deliverable is any product, service or result that must be provided to complete the project and achieve its outcomes. There are different categories of deliverables, best described as Internal and External. Internal are the deliverables required for the project to run (project management materials, reviews etc.); external are the deliverables for the users, clients or customers (systems, products, services etc.),
Stakeholder identification and analysis
The project initiation phase also requires the identification of key stakeholders and their interest/ involvement in the project. The stakeholder analysis developed in the initiation phase will be expanded in the planning phase, and we will focus our discussion on when we reach that part of the process.
Remember though, a stakeholder analysis must be conducted in the initiation phase to ensure you fully understand the impact of the project on people and groups inside and outside your organisation.
Influence and interest matrix
- Quadrant 1: High/High
- These stakeholders have a high vested interest in the successful delivery of your project, usually because it will impact what they do or how they work with you. They also have a high influence over the success of your project, largely because they have a role within it. This could be as a Project Sponsor, a team member, or the manager of a team you need something from to ensure delivery.
- Quadrant 2: High/Low
- These stakeholders still have a high interest in the successful delivery of your project, but their ability to influence the success of it is low. These are likely to be people at the end of a value chain, or people who will use what you are implementing but they are not part of the implementation itself. These could be staff who will use the new system, but they are not part of the project to deliver it.
- Quadrant 3: Low/High
- These stakeholders have a low interest in the delivery of the project, usually because there is no or minimal impact on their work or how they engage with you. However, they still have a high influence over the success of the project because they have a role to support or deliver it – this could be the Finance Manager who will provide you with your budget allocation and process invoices.
- Quadrant 4: Low/Low
- These stakeholders have low interest and low influence on your project. They are the groups or individuals with no vested interest in the project and no role in its delivery. This could be people who receive your services or products, who do not have to change their actions or behaviours.
Once all stakeholders have been identified, you can use the Stakeholder Commitment Curve to assess and define their level of commitment towards your project. It shows us the two paths that can be taken to achieve stakeholder commitment to a project.
Commitment grows from the bottom of the curve to the top and can branch in two directions. The left-hand branch represents a project where commitment is attained because it has to be done. This type of commitment is known as compliance.
The right-hand branch represents a project which is embraced because they want it to happen and see the benefit in a positive outcome. This is where real “hearts and minds” commitment occurs.
Along each path, there are phases stakeholders pass through and how you manage them through these processes will influence the final outcome.
Stakeholder Commitment Curve
Planning the Project
Once your project is approved and established, you should start to develop a more detailed understanding of the requirements of your project. The Project Management Plan is the mechanism most organisations use to capture:
- Detailed analysis of the project stakeholders, requirements and strategies
- Detailed definitions of the work, which will include the work breakdown structure and deliverables
- Detailed estimates of project resources and timeframes:
- Resources include people, expertise, materials, facilities, equipment, money etc.
- Timeframes include capturing the milestone delivery, and dependencies and developing a critical path
- Project risks which identify the owners, mitigation or management strategies
- Project quality strategies, guidelines and management activities
- Communication strategies and plans for the project.
Project updates and registers
Alongside the project management planning documents, the Project Team will create and manage a set of reporting and management documents to support the process. The organisation and size of the project will drive the amount and detail of this documentation. But during the implementation phase of the project, the team will usually manage:
- Project report to appropriate governance bodies
- Project Issues Register
- Project Risk Register
- Project Budget
- Project Gantt Chart
- Content calendar/schedule for communications.
The following sections are all part of the planning process. Some of them also extend into the implementation phase of the project.
Defining activities and milestones
To appropriately manage the scope of your project you need to include a detailed list of:
- All the work required, and
- Only the work required.
Part of this was already developed and identified in your initiation phase. During that phase, you developed a high-level definition of the project scope, resources, timeframes and deliverables.
A significant part of the scope management process is to refine these high-level requirements into granular scope definitions, scope control plans and a work breakdown structure (WBS).
There are a range of actions and planning processes you will undertake in this stage. For now, our next task is to clearly define the project milestones, which creates a detailed understanding of the timings and resources for the project and is the catalyst for the more detailed WBS.
A milestone is a particular point in the project that is used to measure progress towards the ultimate goal. They can include review or input dates, budget checks, due dates for major deliverables and many more activities, events or processes.
Initial WBS planning – using sticky notes
What is it?
Planning your work breakdown structure with sticky notes is a process tool that can be used to create a high-level milestone plan at the beginning of any project.
Why use it?
It helps steer and support key decisions around a project. It can help you plan and decide:
- What to do
- When to do it
- Who will do it
- How long it will take.
When to use it?
Planning your milestones with sticky notes is done in the early stages of a project when it is important to establish your WBS. We do this for a number of reasons:
- To assess the project’s feasibility
- To look for interdependencies with other projects
- To review resource requirements
- To assess and develop a financial case
- Sequence and structure tasks.
Who uses it?
This process can be used by either an individual or a small group of people who are working together on a project – it is preferable to get a group of people together who are specialists in their areas and are more likely to identify areas you would not have considered.
Watch the video Project Planning with Sticky Notes and try it for yourself using your project:
Capturing timeframes and dates
After identifying all the milestones, the amount of time required to complete them, and the responsible people in the organisation – you can develop a Gantt chart with dependencies.
Gantt chart
A Gantt chart is a tabular and visual representation of tasking, like the image below. It allows people to better visualise the timeframe for the project, where the milestones sit, and the current status of tasks.
If you are using sophisticated project management software, there is a range of details you can identify in the system: start and end times; dependencies of the activities; the resources allocated to the activity, and whether they are overtasked; the percentage complete, etc.
Importantly, the dates and dependencies allow these systems to automatically monitor the flow on effects of delays in activities that later activities rely upon. If you are managing this manually, you might miss some of these connections.
Estimation issues
Most people work on an optimism bias when they calculate the time an activity will take. Further to this, project managers often fail to consider the project management requirements for a task. When you are learning to estimate, add 50 percent to your initial concept and you will probably come close to the figure – remember to review this at the end to improve your estimation skills.
Understanding the resources required
Once you have defined the discrete pieces of work required to deliver your outcomes and objectives, you can work out the resources required for your project. You should have done a high-level budget for the Project Scope, but this is where you get more detailed again.
Your resources will include things like:
- Project Team members – can include skills and knowledge required for each deliverable and the hours, to help you determine the team makeup
- External procurement for deliverables – the consultants, experts, products and services you need to purchase as part of your deliverables. This could be things like the software and specialist IT professionals, or office equipment and removalists
- Insurances – where you might need this for the activities you are conducting
- Supporting materials – communication and training collateral required to conduct the project and keep people informed
- Facilities and resources – rooms, AV resources and similar required for use in communication, training and housing the project team.
Ongoing costs
It’s also important at this time to define the ongoing costs that might be associated with the ‘business as usual' handover of your project. Things like annual licensing fees, rental fees, insurance and warranties etc. You should have an estimate of this in your Initiation document, so as this is clarified in the planning and delivery phase you need to capture it for handover.
A Note on Project Integration
As you progress through the planning process, you need to continually review the potential impact of your new decisions on previous decisions. For example, the risk mitigation strategy you choose might require additional funds or resources, so these will need to be adjusted.
Identifying project quality
It is important for you to define how you will evaluate and maintain quality assurance for your project. Certain projects will require a very explicit and compliant assurance program, especially projects that are being delivered to a certain quality standard – like construction or some manufactured products.
The quality process could mean you will manage and review the following details.
- Issues raised by your governance body, sponsor, team, contractors and stakeholders
- Formal Issues Register process. You would need to define how these issues are captured by your team, documented, resolved and communicated back to the original reporter.
- Whether the deliverables received are fit for purpose and meet the stated requirements
- Outline the review process, who will be involved, how the deliverable will be evaluated and what will happen if it does not meet the brief.
- A formal Change or Variation request process to appropriately capture, review and implement required variations to the plan
- Outline the process for requesting a change (form); how these are reviewed, by whom; and how changes are formally captured and relevant people notified.
- Project management processes and performance through an identified audit program
- Plan for, conduct and capture quality audits on the performance of the project, to ensure identified processes and procedures are being followed.
- Records and other requirements for documentation for the project, and for the business-as-usual operation/maintenance of the deliverables
- Outline where and how project documents/records will be stored and which records will be transitioned to the business owner on completion.
Developing your communications plan
The biggest issue with projects is the ambiguity and uncertainty of the change they are creating. Therefore, as the project manager, it’s important for you to provide certainty and clear messages about what is actually going to happen, and when.
Nature abhors a vacuum. If you are not communicating, someone else will – and that’s where the misinformation and disinformation begin.
To achieve this, you need to develop a detailed communication plan. This will take the information you developed for your stakeholders, to develop a more detailed picture about what communications they will receive, how they will receive it and how often that will happen.
Project lifecycle and communications
Communication can seem so obvious to us, that at first, it may seem unnecessary to give much time to planning one’s approach. However, given all the attributes that impact how we receive messages, it is imperative that we know where communication is vital, what our approach will be, and address the preferred communication style and therefore needs, of each and every one of our stakeholders.
Be assured, particularly for major projects that poor communications planning will almost certainly impact negatively on outcomes.
Managing Risk
One of the more important elements of project management is to identify, assess and prioritise the potential risks to the activities, resources, schedules and other aspects of the project. Once the risks have been identified and evaluated, the risk management process assists the Project Manager in minimising, mitigating, monitoring and controlling the probability and impact of these events.
Projects can experience positive and negative impacts from risks, although we generally tend to focus on the potential negative impacts. Importantly, a project might be affected by known and unknown risks – where an unknown risk is an event that impacts the project but had not been identified previously.
Risk breakdown structure
PMBOK includes the following Risk Breakdown Structure (RBS) figure, which …lists the categories and sub-categories within which risks may arise for a typical project.
Consequences and likelihood
- Consequence (Impact)
- How severe could the outcomes be if the risk event occurred?
- Likelihood (Probability)
- What’s the chance of the risk occurring?
Building the register
This is best done in a group, like your Work Breakdown Structure. Since you are unlikely to be aware of all the potential risks for all the activities, it’s important to include your key stakeholders in the development of your risk register.
- Hold a meeting to discuss the risks – encourage your meeting participants to be as creative as they can with the statement “what could go wrong?”
- Capture all the ideas as ‘potential risks’ – don’t dismiss anything at this stage.
- Go through the brainstormed ideas and evaluate whether they are actual risks – you will likely remove some of the more creative ones from the list.
- Assess the Likelihood and Consequence of each one as a group – do not allow either of these to be downplayed by members of the group. Understand that biases might be at play, and people might have an unconscious bias about the likelihood or consequence of an action.
- Once rated, conduct an activity to deal with the risks – most often this will be mitigation strategies.
The organisation has four possible responses to risk:
- Avoid
- Used for high likelihood and consequence events; requires replanning to avoid the risk entirely.
- Transfer
- For low likelihood but high consequence events; requires finding another party to take the risk, like and insurer or contractor for specific services.
- Mitigate/Reduce
- For high likelihood but low consequence events; identification of actions that can reduce the probability through active management, communication, etc.
- Accept
- Only for low likelihood and consequence events; doesn’t require any additional actions.
Implementing the Project
Managing expectations and scope creep
As the Project Manager, it is your role to manage the expectations of your stakeholders and manage the deliverable scope of your project. Communication and engagement are the keys to this, but it’s important to remember that communication is a two-way street:
While you might think your message is clear, the receiver will interpret your message and decode it based on their internal view – they might hear what they want to hear, and not what you said to them at all!
It is vital to continually check their understanding of your message, to provide it in different forms and be explicit about what is and is not part of your project – and exactly when that will or will not occur.
Building the team
| Project roles | Responsibilities |
|---|---|
| Sponsor |
|
| Manager |
|
| Team |
|
- Identify and select
- Introduce and induct
- Roles and responsibilities
- Common understanding
All managers of people need to ensure that their team members understand their roles and responsibilities – projects are no different. Early engagement of team members, which allows them to participate in the project planning phase, is a great way to establish and inform your team. Where this is not possible, you need to ensure your induction processes and documentation cover these requirements adequately.
As well as ensuring individuals understand their roles and responsibilities, it’s important to get the team working together as quickly as possible. You could use Tuckman’s team development model to help move your team to the Performing stage – which is where you need them to be.
Team dynamics
Tuckman’s team development model
Team dynamics can make or break the success of a project. Remember that:
- Each step builds on the previous one
- Each step prepares for the performing stage
- Skipping any step negatively impacts performing
- With every new challenge, the process repeats
- Teams can move back and forth between stages.
| Task | Behavior | |
|---|---|---|
| Forming |
|
|
| Storming |
|
|
| Norming |
|
|
| Performing |
|
|
| Adjourning |
|
|
Descriptions and actions for each stage as they relate to each other
- Individuals are not clear on what they’re supposed to do
- The vision and goals aren’t owned by the group
- Wondering where they’re going
- No trust yet
- High learning
- No group history; unfamiliar with group members
- Norms of the team are not established
- People check one another out
- People are not committed to the team
- Roles & responsibilities are articulated
- Agendas are displayed
- Problem-solving doesn’t work well
- People want to modify the team’s vision or goals
- Trying new ideas
- Splinter groups may form
- People set boundaries
- Anxiety abounds
- People push for position & power
- Competition is high
- Cliques drive the team
- Little team spirit
- Lots of personal attacks
- The level of participation by members is at its highest (for some) and its lowest (for some)
- Success occurs
- The team has all resources for doing the job
- Appreciation & trust build
- The purpose is well defined
- Feedback is high, well-received & objective
- Team confidence is high
- Leader reinforces team behaviour
- Members self-reinforce team norms
- Hidden agendas become open
- Team is creative
- More individual motivation
- The team gains commitment from all members on direction & goals.
- Team members feel very motivated
- No surprises
- Little waste
- Very efficient team operations
- Team members have an objective outlook
- Individuals take pleasure in the success of the team – big wins
- Individuals defer to team needs
- “We” versus “I” orientation
- High pride in the team
- High openness and support
- High empathy
- High trust in everyone
- Superior team performance
- OK to risk confrontation
- Retrospective Thoughts & Discussions
- Anticipate future
- Plan on improvements/ changes etc
- Maybe a sense of mourning
Action steps: Forming to Storming
- Set a mission & vision
- Set goals
- Establish roles
- Recognise the need to move out of the “forming” stage
- Leaders must be directive
- Figure ways to build trust
- Define a reward structure
- Take risks
- Bring the group together periodically to work on common tasks.
- Assert power appropriately
- Decide to be on the team
Action steps: Storming to Norming
- Team leaders should actively support & reinforce team behaviour, facilitate the group for wins, and create positive environment.
- Leaders must ask for & expect results
- Recognise, and publicise team wins
- Agree on roles & responsibilities.
- Buy into objectives & activities
- Actively listen to each other
- Set & take team time together
- Everyone works to set a supportive environment
- Have the vision: “We can succeed!”
- Request & accept feedback
- Build trust by honouring commitments
Action steps: Norming to Performing
- Maintain traditions
- Praise & flatter each other
- Self-evaluate without a fuss
- Share leadership role in a team based on who does what the best
- Share rewards and successes
- Communicate all the time
- Share responsibility
- Delegate freely within the team
- Commit time to the team
- Keep raising the bar – new, higher goals
- Be selective of new team members; train to maintain the team spirit
Execution and monitoring
While it’s important to develop a robust project plan, the key to managing a project is the control and monitoring of its implementation. This is when the hard work begins; as issues arise, risks are realised, delays creep in, team members become challenging, stakeholders become problematic and the project deliverables are realised.
As mentioned in the planning phase, the project team should define and develop a range of documents that are used to assist in the delivery of the project. These include:
| Project report to appropriate governance bodies | As well as keeping your governing body up to date, this report is used to escalate issues and seek executive support for resolving issues, risks, unforeseen budget impacts, communications and anything else that is affecting your ability to deliver on time and budget. |
|---|---|
| Project Issues Register | Used to capture any identified issues that might impact on the delivery within time, budget and identified quality. These issues could be identified by the team, or by other stakeholders. It’s a monitoring tool to help manage potential problems and their resolution. It is also part of your change management, identifying a lack of, or reduced, support from areas of the business. |
| Project Risk Register | The Risk Register should be regularly reviewed to capture any newly identified risks and their mitigation strategies. It should also be maintained to remove risks once they are no longer relevant to the project. Maintaining an awareness of risks and their strategies will ensure you are prepared to act should a risk occur. |
| Project Budget | The Project Manager needs to actively manage the budget and expenditure of the project. Some organisations might not be set up to easily capture and identify project expenditures. Regardless of this, the Project Manager must find a way to regularly capture all outgoing costs against the budgeted figures, so they can take appropriate action in the case of unexpected costs or overspending. |
| Project Gantt Chart | The Gantt Chart is a simple way to capture the progress of the project against the identified tasks, deliverables and milestones. The team can use this document to easily understand the impacts of delays, and their flow on effect to the remaining tasks and deadlines. It is particularly important to monitor this in relation to communications and key messages, so you can provide appropriate updates to stakeholders if delays occur. |
| Content calendar/schedule for communications | As noted above, this needs to be managed alongside the Gantt Chart to ensure alignment of communications and outcomes. The content calendar also ensures communications are developed in a timely manner, and you are deconflicting messages so you do not overwhelm stakeholders if and when things change. |
| Change/Variation Log | If you are using a Change/Variation Request process as part of your scope management then this would be used to manage and review that process, ensuring you understand the impact on any ‘scope creep’. |
Your organisation may have their own systems in place to manage these processes – reporting dashboards from key systems, systems to capture and report on issues and risks, traffic light financial reporting, etc. As a project manager, you must ensure you maintain complete awareness of all deliverables, and any issues that might impact their successful delivery – remembering that success should be the on-time, on-budget and within-scope delivery of the project.
Closing the Project
The project does not end when the final deliverable is complete – unless your final deliverable is the closure of the project. Far too often, organisations fail to complete the important handover, analysis and learning processes that should be part of any good project.
As well as remembering to celebrate your achievements and communicate the closure with your stakeholders, there are a few other processes to complete at the end of every project.
Finalising the work
Analysis and acceptance
Before you can clearly state that you have delivered all the project outcomes and objectives, you need to analyse whether you have met your measurable goals. This is usually done through the development of a report that clearly outlines how you have met the requirements outlined in the project scope.
Some of this may have been completed along the way if there were earlier deliverables in the project that have already been accepted by the business. If this has not been done, this report can be used as a means of seeking acceptance from the client that the project has delivered all deliverables within the requirements outlined.
Where the client is not satisfied with a deliverable, this must be resolved prior to closing the project.
Handover
All required documentation, paperwork, contracts, warranties etc. should have been handed over to the appropriate section of the business as part of the deliverables. However, sometimes these aspects are overlooked, or remain the responsibility of the project until such time as all deliverables are complete.
Prior to the closure of the project, it is essential that all ongoing functions, documentation, assets and staff are appropriately transitioned into the relevant business-as-usual section of the organisation. To ensure this is done correctly, consider who will be the ongoing point of contact for stakeholders, and whether they have everything they need to answer questions about why decisions were made and who they can seek support from.
Evaluating the project
Every project should be evaluated against the initial plan – how well did you perform against what you planned to deliver? Questions you might consider in this include:
- Did you achieve the Outcome(s)?
- Did you achieve the SMART Goal(s)?
- Did you meet your milestones on time?
- Did you deliver on budget?
- Did your deliverables meet the quality requirements?
- Were you prepared for any risks or issues that arose? If not, why not?
- Were your communications effective or were there issues with people misunderstanding or not being prepared for activities?
- Did the team perform their roles well – as individuals and as a team?
Lessons learned
Another aspect of the evaluation is conducting a detailed analysis of the lessons learned during the project. It’s often best to consider this document while you are delivering the project, so you don’t have to try to rediscover all your earlier lessons at the end.
The lessons learned should consider everything that did not go exactly to plan; whether there was a way to prevent the ‘lesson’; and how you solved any problems that arose. Importantly, it should also include elements of your planning, team and processes that worked well, and that other project teams could use in future.
Once all your deliverables and final documentation have been accepted by your client, you can close out your project.
In CS203 we learned about the usage of GitHub when working on collaborative projects. Let's take a moment to do a quick refresh.
GitHub is a web-based platform that provides version control, collaboration, and code hosting services. Developers use GitHub to store, manage, and collaborate on software projects using the Git version control system.
GitHub offers a range of features that facilitate collaboration among developers and teams, including:
- Version Control: GitHub serves as a repository for code files, allowing developers to track changes, create branches, and merge code changes efficiently. It enables version control through Git, ensuring the integrity and history of codebase revisions.
- Collaboration and Code Review: GitHub provides tools for collaboration and code review, allowing developers to collaborate on projects in real-time. It supports features like pull requests, issue tracking, and inline commenting, which facilitate code review, discussion, and collaboration among team members.
- Project Management: GitHub offers project management features such as project boards, milestones, and task tracking. These features help teams organize and manage project tasks, track progress, and ensure smooth coordination among team members.
- Community and Open Source Collaboration: GitHub hosts a large community of developers and supports open-source collaboration. It allows developers to discover, contribute to, and collaborate on open-source projects by creating pull requests, submitting bug reports, and engaging in discussions.
Overall, GitHub plays a vital role in facilitating collaboration, code sharing, and project management within software development teams. It provides a centralized platform for version control, collaboration, and community engagement, making it easier for developers to work together and contribute to the success of their projects.
While GitHub is a very useful tool in Software Development let's take a look at some of the other solutions:
- Project Management
- Documentation
- Collaboration
Project Management Tools
Project management tools help in planning, tracking, and organizing software development projects. They facilitate task management, scheduling, team collaboration, and progress monitoring. Some popular project management tools include:
Jira
Jira is a widely used tool that offers comprehensive project management features, including issue tracking, task management, agile planning, and reporting. It allows teams to create and manage projects, assign tasks, track progress, and collaborate on work items.
| Pros | Cons |
|---|---|
|
|
Asana
Asana is a versatile project management tool that enables teams to create tasks, set deadlines, assign responsibilities, and track progress. It provides visual project boards, task dependencies, and integrations with various other tools.
| Pros | Cons |
|---|---|
|
|
Trello
Trello is a popular Kanban-style project management tool that visualizes tasks as cards on boards. It allows teams to create, move, and track tasks across different stages, enabling easy task management and team collaboration.
| Pros | Cons |
|---|---|
|
|
Documentation Tools
Effective documentation is crucial in software development to capture requirements, design decisions, project plans, and other essential information. Here are some tools commonly used for project documentation:
Confluence
Confluence is a collaborative wiki-based documentation tool that allows teams to create, share, and collaborate on project documentation. It offers features such as rich text editing, version control, commenting, and integration with other Atlassian tools.
| Pros | Cons |
|---|---|
|
|
Google Docs
Google Docs is a cloud-based document collaboration tool that enables teams to create, edit, and share project documentation in real time. It provides features for formatting, commenting, and revision history, allowing for seamless collaboration.
| Pros | Cons |
|---|---|
|
|
SharePoint:
Microsoft SharePoint: SharePoint is a platform that facilitates document management, version control, and collaboration within organizations. It offers document libraries, metadata management, search capabilities, and integration with other Microsoft Office tools.
| Pros | Cons |
|---|---|
|
|
Collaboration Tools
Collaboration tools foster effective communication and teamwork among software development teams, allowing for seamless collaboration, knowledge sharing, and remote collaboration. Some widely used collaboration tools include:
Slack
Slack is a team communication and collaboration platform that enables real-time messaging, file sharing, and channel-based discussions. It integrates with various other tools and offers features like threaded conversations, notifications, and search capabilities.
| Pros | Cons |
|---|---|
|
|
Teams
Microsoft Teams: Microsoft Teams is a unified communication and collaboration platform that combines chat, video meetings, file sharing, and collaboration on documents. It provides integration with other Microsoft tools and supports seamless collaboration across teams.
| Pros | Cons |
|---|---|
|
|
Zoom
Zoom is a video conferencing and collaboration tool that enables remote meetings, screen sharing, and team collaboration. It allows teams to conduct virtual meetings, collaborate on documents, and stay connected regardless of their physical location.
| Pros | Cons |
|---|---|
|
|
Project reporting involves the systematic collection, analysis, and presentation of project-related information to stakeholders, team members, and management. It provides insights into the project's progress, status, risks, and overall performance. Here are the key aspects of project reporting:
Types of Project Reports
- Status Reports: Provide updates on the project's overall progress, accomplishments, milestones achieved, and potential risks or issues.
- Financial Reports: Focus on project budgets, expenditures, cost tracking, and financial projections.
- Risk Reports: Highlight identified risks, their impact, probability, mitigation plans, and risk response strategies.
- Resource Reports: Provide information about resource allocation, utilization, and any challenges related to team capacity or skills.
- Progress Dashboards: Visual representations of key performance indicators (KPIs), project metrics, and milestones.
Reporting Frequency and Audience
- Determine the frequency of reporting, which can vary based on project size, complexity, and stakeholder needs. It can range from weekly to monthly or customized intervals.
- Identify the intended audience for each report, such as project sponsors, executives, team members, and other relevant stakeholders.
Key Components of Project Reports
- Executive Summary: Provides a high-level overview of the project's current state, progress, and key highlights.
- Project Summary: Includes a brief description of the project objectives, scope, timeline, and key deliverables.
- Progress Updates: Details the accomplishments, milestones achieved, tasks completed, and tasks in progress.
- Risks and Issues: Identifies and analyzes project risks, issues, and mitigation strategies.
- Resource Utilization: Provides insights into resource allocation, workload distribution, and any resource-related challenges.
- Financial Summary: Covers the project budget, expenses, and financial status.
- Next Steps: Outlines upcoming tasks, milestones, and planned activities for the next reporting period.
Project Documentation
Project documentation involves capturing and maintaining essential information related to a project's planning, execution, and outcomes. Proper documentation ensures the availability of accurate and up-to-date project information. Here are some key aspects of project documentation:
Types of Project Documents
- Project Charter: Outlines the project's objectives, scope, stakeholders, and high-level project plan.
- Project Plan: Provides a detailed roadmap of project activities, timelines, milestones, resources, and dependencies.
- Requirements Documentation: Captures the project's functional and non-functional requirements.
- Design Documents: Describe the architecture, system design, and technical specifications.
- Test Plans and Reports: Detail the testing approach, test cases, and results.
- Change Control Documentation: Documents changes made during the project, including change requests, approvals, and impacts.
- Lessons Learned: Summarizes key insights, successes, challenges, and recommendations for future projects.
Document Versioning and Control
- Implement a version control system to track changes, updates, and revisions to project documents.
- Establish clear guidelines for document naming conventions, storage locations, and access permissions.
- Use collaborative tools or document management systems to facilitate document sharing, editing, and versioning.
- Documenting Project Decisions
- Record important decisions made during the project, including rationale, impacts, and alternatives considered.
- Documenting decisions helps maintain project transparency, ensure continuity, and provide a reference for future projects.
Accessibility and Maintenance
- Ensure project documents are easily accessible to project team members and stakeholders.
- Regularly review and update project documentation to reflect changes, lessons learned, and project outcomes.
Summary
By implementing effective project reporting and documentation practices, you can enhance project communication, provide transparency, and maintain a comprehensive record of project activities, progress, and outcomes.
