Agile Lean Conference 2016 - Spagnuolo S_Leadership, resilienza & Agile PM
Agile PM Primer 2008
Transcript of Agile PM Primer 2008
-
7/28/2019 Agile PM Primer 2008
1/18
Agile Project Management
A Primer
-
7/28/2019 Agile PM Primer 2008
2/18
Agile Project Management A Primer
1 2007
gile Project Management (also known as eXtreme or Radical Project Management) is an integrated set oftools and techniques for managing the new types of projects that have emerged in all organizations.
These projects are typified by:
unstable requirements within evolving organizations;
complex stakeholder inter-relationships;
innovative business requirements;constrained deadlines, budgets and people; and
tight focus on strategic alignment and added value realization.
Traditional project management approaches (such as those in Prince 2 and the Project Management Institute)have failed to adapt to these projects and, as in other industries such as manufacturing and construction,new approaches to business and IT project management are demanded. While it is fashionable to deride
traditional project management (typified by the PMBOK), these approaches worked well in the stable andengineered projects of the past. Simply, creative and dynamic project management must replace the over-engineered and mechanistic project management of the past as projects (and organisations) become morecreative, agile and dynamic. Agile Project Management is simply the management of creativity.
Agile Project Management [APM] can be best understood through a comparison to traditional projectmanagement (TPM):
TPM focuses on the development cycle of products and systems,
APM focuses on the whole-of-life of products and systems (development, support and benefitsrealization).
TPM treats quality, project risk and cost-benefit as plug-ins to scheduling,
APM fully integrates quality, project risk and cost-benefit into the planning and managementprocess.
TPM treats team members as a resource that has costs and require constant tracking and review,
APM treats team members as creative and motivated people who will work to achieve the projects
success.
TPM focuses downwards to the team and the managing the teams deliverables (cost, schedule,etc),
APM focuses outwards and upwards towards the Sponsor, stakeholders and clients.
TPM focuses on costs;
APM focuses on benefits realization.
TPM is expensive, report and forms-laden, slow and bureaucratic,
APM is inexpensive, low-tech, rapid and open.
There are many other distinctions, which include open participative planning (RAP sessions) andevent/scenario planning.
Most importantly, APM is based on open and collaborative partnerships between the project manager and thestakeholder/clients.
The two principle project management culturesProject management models also reflect a specific culture and value system and the resultant behaviors havea significant impact on how project management is perceived and deployed within organizations. More
importantly, the specific project management culture can have a major impact on the effectiveness of project
management.
Traditional project management, which is the most widely implemented and documented approach to projectmanagement in organizations has a set of values and behaviors that were borrowed from the constructionand engineering industries that laid the foundation of all the key models such as scope, schedules and so on.
These values and associated behaviors are:
Closed Project management is undertaken by experts, who dont needinput from users. The project manager owns the project theteam, the budget, the scope and so on;
A
-
7/28/2019 Agile PM Primer 2008
3/18
Agile Project Management A Primer
2 2007
Distrust Project team members and stakeholders need to be motivated,monitored and questioned at all times. If you dont monitorclosely people will slack off. All estimates are padded and needto be haggled down;
Dishonesty The true status of the project is to be positively presented. Notasking for help is seen as strength and telling managementwant they want to hear is quietly encouraged. Projects are
reported as Green or Amber to avoid executive attention andpossible punishment. Red status is reported at the lastpossible moment. Additional examples include inflating benefitsand understating costs to ensure project gets approved;
Lack of courage Not standing ground as professional, selling out the team and/or stakeholders by agreeing to unrealistic expectations (time,budget, scope, etc.), asking for help and assistance are seen asa sign of weakness as is admitting uncertainty and mistakes;
Technical fun The project is justified on the belief that great technology willautomatically generate benefits. The more impressive thetechnology the most impressive the curriculum vitae. In
addition, benefits analysis and realization belong to the usersnot the project manager.
Agile project management (APM) evolved in leading business and IT areas as an alternative to the perceivedbureaucracy and implied values and behaviors of Traditional project management. Agile project managementvalues and behaviors are:
Open Project management involves full participation and ownershipby relevant stakeholders (including sponsors) and is
facilitated by the project manager. The project manager ownsthe process not the project and its outputs and outcomes;
Trust Project team members, sponsors and stakeholders areprofessionals. They can be trusted to work hard and becommitted to the project and the organization. If trusted, theywill personally commit to work as hard as required not tobetray the trust given to them. They will be honest with
estimates if given the chance;
Honesty All people impacted by or involved in the project have a rightto be told the truth and inflating benefits and underestimating costs is not acceptable. The right to say I dontknow the true estimates, can I have some time are seen asacceptable;
Courage Undertaking projects requires courage in many areas - telling
the truth, asking for assistance, admitting uncertainty andmistakes are signs of strength, acting as a professional;
Money Projects consume shareholders, citizens and corporate moneyand this requires a fiscal and ethical responsibility i.e. a dutyof care to be shared by all team members, project manager,sponsor and stakeholders. Benefits realization is theresponsibility of stakeholders but project managers must
engage stakeholders and sponsor in ensuring that thebenefits realization is planned and funded.
After 35 years of project management consulting, teaching and mentoring, we have come to understand isthat, like children born in a specific culture that has been absorbed into the daily family rituals, education,media, laws and so on that surrounds the child, most people involved in projects, project management andproject governance have become victims (or, at least, passive participants) of a culture its values and itsbehaviors.
-
7/28/2019 Agile PM Primer 2008
4/18
Agile Project Management A Primer
3 2007
Agile Project Management: OverviewAgile project management is the management of creativity and innovation. It involves balancing two, oftenconflicting, concerns. The concerns are the technical aspects of the project (the content) and the managerialaspects of the project (the context). The technical aspects deal with the development of the specific outputs ordeliverables of the project. The managerial aspects deal with the broader organization, financial, resource and
time-frames of the project. Project management is different to technical management. It involves managing the
context. All the research shows that projects that fail,failin the context not the content.
There are five basic processes in managing projects.
Prioritize, Steer and Review Projects provides the executive governance - project sponsorship. Project
Feasibility Assessment examines both the managerial and technical feasibility and risks. Project Planningdevelops the projects Business Case. Project Tracking monitors plans against actual status. Project Reportingreports the status of the project and Business Case to the Project Sponsor and stakeholders.
Project Planning (RAPs)
There are six steps in project planning which develops a Business Case and associatedproject schedule.
These steps should be followed in sequence however some iteration or looping back willbe required. For example, the initial project schedule may not meet the deadline so the
project development strategy may need to be changed and the risks, tasks and estimateswill be altered. Project planning should be conducted as an intensive team-basedprocess involving key stakeholders and support groups such as Human Resources andAudit. RApid Planning (RAP) sessions are planning sessions where the stakeholders and team membersundertake the project planning process following the six steps in sequence. You, the project manager, shouldact as the facilitator of the RAP.
Planning is a
creative problem
solving process.
Planning is working ..
working is not
planning
MANAGERIAL TECHNICAL
Policy Specifications
Procedure Manual Design
Work Redesign Models
Education Modules
Test Plans
Communication Strategy
Implementation Guides
Legal Advice
Public Relations Material
Stakeholders
Related Projects
Risks
Returns
Costs
Schedules
Priorities
Estimates
Resources
Assumptions
10 - 20%
Scope
Objectives
Strategy
Quality
80 - 90%
Relative effort spent on each process
Prioritise, Steer and
Review ProjectsPrioritise, Steer and
Review Projects
Project
PlanningProject
Planning
Project
TrackingProject
Tracking
Project
ReportingProject
Reporting
Project Concept Project Business
Case
Project
Feasibility
Assessment
Project
Feasibility
Assessment
-
7/28/2019 Agile PM Primer 2008
5/18
Agile Project Management A Primer
4 2007
The RAP process (and associated tools) is the critical underpinning technique of Agile Project Management.
Project planning produces the Business Case which is the key management contract between the informationsystem development group and their clients. Any changes to the approved Business Case must be approved
by the Project Sponsor, Owner or Steering Committee.
Before you start planning, define success for the project
Agile project management adopts a whole-of-life perspective. Both the development and the support stagesare planned and managed. This enables both the realization of benefits and the measurement of total costs -development and support.
The first and most important step in planning a project is to negotiate the expectations of success. Traditionalproject management defined success within the limited framework of the development stage of the project -
meets requirements, on time and in budget. Agile project management defines success from a developmentandsupport perspective.
Determine
Project Scope and
Objectives*
Determine
Project Scope and
Objectives*
Select Project
Development
Strategy
Select Project
Development
Strategy
Analyse Project
RisksAnalyse Project
Risks
DevelopProject Task
List
Develop
Project Task
List
Estimate
Tasks/ProjectEstimate
Tasks/Project
Develop Project
ScheduleDevelop Project
Schedule
Project Concept Project Business Case
* includes Stakeholder Analysis,
Quality and Success Definition
Benefits
Costs
Development Support
Benefits Realisation Review
Post Implementation Review
FeasibilityAnalysis
DesignBuild
TestShip
-
7/28/2019 Agile PM Primer 2008
6/18
Agile Project Management A Primer
5 2007
Before planning, each critical stakeholder group defines success using the sliders. This negotiation shouldbe done before any detailed planning.
Establish project objectives, scope, stakeholders
Scope and objectives
Scope is a statement of the area of responsibility of the project manager. Scope should state the boundary ofthe project and the objectives should state what to achieve and the specific responsibilities of the projectmanager.
PROJECT :
IS NOT [Could be]IS
NOT RESOLVED
The objectives in scope are the responsibility of the project manager. The
objectives outside scope are generally the responsibility o f stakeholders. The
unsure objectives must be resolved by the sponsor.
ONOFF
have a satisfied client group/s
meet the project's objectives/requirements
meet an agreed budget - resources, capital, equipment
deliver the product on time
add value for the organisation
meet quality requirements
have a sense of professional satisfaction for the team
Off- Success Factor is not relevant. It is measured however. On - Success Factor is relevant. Degree of relevance is indicated by position of slider.
ONOFF
ONOFF
ONOFF
ONOFF
ONOFF
ONOFF
-
7/28/2019 Agile PM Primer 2008
7/18
Agile Project Management A Primer
6 2007
Objectives are what the project is designed to achieve within the scope. Objectivesshould be specific and measurable and should identify business problems that are beingsolved. They should be stated with some benefit or end result in mind. The scope and
objectives of the project can be combined by stating what objectives are in the scope ofthe project and what related objectives are outside the scope of the project.
Developing a clear and precise statement of your projects scope and objectives is the
most important step in planning a project.
This tool should be used during the planning session to identify the project's objectives and, by documentingrelated objectives outside the project, scope is defined as well. The results from completing this form can be
stated as scope and objectives in the Business Case.
Any un-resolved objectives should be forwarded to the Project Sponsor or Steering Committee for advice andresolution as soon as possible.
The trick here is that while you, as the Project Manager, are responsible for the Is objectives, you mustunderstand the related Is Not objectives and manage the relationship with the stakeholders and relatedprojects that are undertaking the objectives outside scope.
Stakeholders and related projects
The project manager and team should identify any critical stakeholders and related projects. Stakeholders are
people or groups outsidethe project manager's direct organizational control who must either provide a serviceor receive a service to or from the project. Critical stakeholders are generally those whose service is vital to theproject's success. Related projects are a special form of stakeholder. A related project is a project that sharespolicy, process, technology, staffing, finance or staff impact with the project.
Given that there can be many stakeholders and related projects for your project, you should partition yourstakeholders and related projects into the following structure:
Critical - the stakeholder or related project can stop your project
from achieving its objectives/outputs/outcomes -showstopper - has veto rights
Essential - the stakeholder or related project can delay yourproject from achieving it'sobjectives/outputs/outcomes - delayer -possible veto
Interested Party - the stakeholder or related project has an interest in theproject - no veto.
The Partnership Agreement is vital to the management of project stakeholders and related project managers.
Project or Partnership Agreements
The project manager should formally document any services required by key stakeholders and related project
managers.
A project
without a clear
statement of scope
and objectives will
fail and, indeed, has
failed before it
started.
Project Title : ______________________ Date : ___/___/___
Stakeholder : _______________________
Services Required Timing Cost Contingency Person Responsible
List all the services,
deliverables required by of
from the stakeholder
Agree on effort
or deadline
requirement for
the stakeholder
Determine if
the stakeholder
is going to
charge you for
the service
Negotiate who
else can
provide the
service if the
stakeholder is
not available
Optional - agree
which team member is
responsible for the
management of the
relationship
-
7/28/2019 Agile PM Primer 2008
8/18
Agile Project Management A Primer
7 2007
These agreements are designed to ensure that any key stakeholders or related projectmanagers have been involved in the project planning process and that they areprepared to support the project.
Key issues that should be agreed to in the agreements are:
services involved;
required timing of services;
any costs incurred for the service;any contingency person.
Stakeholder buy-in for your project is mandatory and the use of the RAP session which fully involves criticalstakeholders in planning the project and developing the Business Case is a great way to get that buy-in.
A Primer on BenefitsThe process of analyzing and estimating the benefits that the project is seeking to realize is driven by the
projects objectives. As shown in the diagram, an objectiveproduces an outputwhich, in turn, leads to anoutcome.
The key to understanding benefits is that there are only three classes of benefits:
I.R. - the objective leads to a direct increase of revenue;
A.C. - the project leads to an avoidance of actual (i.e. staff reduction) or notional costs (i.e. there is
an increase in productivity);I.S. - the project improves service to an internal or external client.
Other Added Value Drivers
It is also reasonable to include factors such as Strategic Impact, Technology Impactand Organizational Impact as additional drivers to the financial analysis of R.O.I.(Return-On-Investment).
The additional factors should be assessed using a common process and would be usedalong with Project Risk and Quality to assist in cross-project prioritization.
Define QualityThis tool is designed to assist you in gaining a more rigorous definition of the quality that your sponsor andcritical stakeholders require for the product.
If your benefits
are intangible, then the
amount of executivesupport you will receive
will also be intangible.
ObjectiveObjective OutputOutput OutcomeOutcome
An objective must An output is the An outcome is the
state "what" is direct change in the indirect change in the
going to change in status-quo as a result status-quo as a result
the status-quo. of the objective of the outputbeing
"delivering". used to achieve a
"secondary" change
ObjectiveObjectiveOutput
[Team]
Output
[Team]Outcome
[Stakeholder]
Outcome
[Stakeholder]
Primary Benefit
Increase Revenue
Avoid Costs
Improve Service
Secondary Benefit
IncreaseRevenue
Avoid Costs
Your project
stakeholders can be
your worst enemy or
your best friends it
depends upon how
you communicate to
and involve them in
your project.
-
7/28/2019 Agile PM Primer 2008
9/18
Agile Project Management A Primer
8 2007
During the RAP session, you should ask each critical stakeholder to negotiate which of the quality attributesmatters to them. Clearly, there is going to be major disagreements between the various stakeholders and youneed to either, look for the majority view on each attribute or, alternatively, ask your Project Sponsor to decideunilaterally.
Project Development Strategy/ScenariosThe selection of the project development strategy is one of the most important decisions made during theproject planning process. The project development strategy is different to the product development cyclewhich is the technical tasks involved in building products. The project development strategy determines theoverall approach to the building of the product.
There are five basic project development strategies:
monolithic - where the total project requirements are developed in one sequence through theproduct development life cycle;
sequential release - the project's requirements are broken into components or events and one
component is developed sequentially through the product development cycle and placed intoproduction. The next component is then developed through the product development cycle. Agiledevelopment is a highly-focused version of this strategy;
concurrent release - the project's requirements are broken into components and each componentis developed as separate releases concurrently. Each release follows the product developmentcycle;
fast-track - the project's requirements are developed as quickly as possible using the minimumactivities of the product development cycle. The "fast-tracked" production product is reviewed andimproved using another fast- track project. This strategy is also called production prototyping orrapid development; and
CONFORMITY
USABILITY
EFFICIENCY
MAINTAINABILITY
REUSABILITY
FLEXIBILITY
RELIABILITY
PORTABILITY
AUDITABILITY/SECURITY
JOB IMPACT
ATTRIBUTES
Does the product have the
desired data, function andprocedures as required?
Is the product easy to use, learnand understand from the enduser's perspective?
Does the application use thehardware, system software andother resources efficiently?
Is the system easy to maintainand correct?
Does the system use code anddata that is c apable of beingused by other systems?
Is the system easy to enhance inorder to add or modify functionand data?
Does the system operatewithout failure and with
consistency?
Is the system easy to migrateto another hardware, softwareenvironment?
Is the system secure fromunauthorised access and is it
auditable?
Does the system provideacceptable working environmentfor direct users?
M - MANDATORY N.A. - NOT APPLICABLE
Project :
CRITICAL EXTERNAL GROUP OR STAKEHOLDER
Date : ..../..../....
Page ...... of .......
-
7/28/2019 Agile PM Primer 2008
10/18
Agile Project Management A Primer
9 2007
hybrid - a variation of concurrent release where different strategies are used for each component.For example, one release may be fast-tracked while another uses the monolithic.
The choice of strategy is dependent primarily on three factors:
project risk;
team size; and
project duration (in time).
Basically, the higher the risk, the longer the project and the bigger the team size, the more useful are the fast-
track and hybrid strategies. The monolithic strategy should only be used for projects that are low risk andless than 3 months in duration, in general.
Events are an alternative concept to deliverables. An event is simply a significant point in a project.
Scenarios are alternative paths through a particular strategy. Agile development is a highly aggressive form ofSequential Release.
Analyse
Requirements
Design
SolutionBuild
Implement
Solution
Analyse
Requirements
Release 1
Design
Release 1
Solution
Build
Release 1
Implement
Release 1
Solution
Analyse Overall
Requirements Release 1 Release 2
Release/Version
Analyse
Requirements
Release 2
Design
Release 2
Solution
Build
Release 2
Implement
Release 2
Solution
Release 1
Release 2
Sequential
Minimum
Deliverable
Concurrent
Analyse Overall
Requirements
Analyse
Requirements
Version 1
Design
Version 1
Solution
Build
Version 1
Implement
Version 1
Solution
Fast-Track
Version 1
Review &
Reengineer
Version 1
Cut
corners/
ASAP
Fast-Track
Version 2
Fast-track/Evolutionary
Monolithic/Waterfall
-
7/28/2019 Agile PM Primer 2008
11/18
Agile Project Management A Primer
10 2007
Complete risk assessmentProject risk management has two related processes. First, you assess the risks andsecond, you attempt to reduce and/or contain the high risks.
Project risk assessment is a structured evaluation of risk factors that have been shown
to affect the project's probability of success. The identification and elimination orreduction of high risk factors associated with the project is a key project planning
process.
The following process should be applied to risk assessment:
using the form opposite each member of the team, stakeholders and project manager completes therisk factors questions from their own perspective;
the members of the planning session then share their answers and discuss any major areas ofdifference in each person's risk factor assessment;
after the discussion, if there is no consensus, a vote is taken on each risk factor with the majorityvote being taken as the project risk factor - if the vote is tied then the worst case is selected;
in the form on the next page, the overall risk is the sum of all risk factors though some factors maybe given more weight than others. In other words, while the majority of the risks may be ranked asMedium because the requirements are assessed as unstable and the project has a fixed deadline,the overall ranking may be adjusted to High.
Attempts should be taken during the planning session to try to minimize the impact of any high risk factors.
This will involve negotiation with the Project Owner, Steering Committee and project manager. Other actionssuch as changing the project development strategy could also be required to reduce project risk.
The second process of risk management is to analyse all high risk factors and develop a reduction orcontainment strategy. Any unresolved high risk factor should be documented as a Risk Memorandum withwould include:
the risk factor;
the impact of the risk factor on the project;
potential risk minimization strategies; and
contingency actions should the risk factor "switch on"
The Risk Memorandums are included in the Business Case. The high risk factors should be monitored closelyduring the product development cycle. The process of Risk Memorandums is the essential pro-active elementof risk management
This is the basic tool for assessing the risks of a project. It is completed during the RAP session.
The risk assessment process should be undertaken democratically with all team members and criticalstakeholders being involved.
Business versus Project Risk
The Business Risk of a project is the exposure (legal, financial, image, etc) that your company or organizationfaces should your project fail. The Project Risk is the factors that could cause your project to fail. Both sets ofrisk should be analyzed in conjunction with your Internal Audit or Risk Management gurus. Business Risk isclearly the concern of your Project Sponsor. A full model of Risk Management would include BenefitsRealization Risk, Production Support Risk and Personal Risk.
Project Risk Impact
Project risk affects all aspects of projects however, the significant impacts are include:
Estimation accuracy the higher the risk the more likely initial estimates are incorrect;
Estimation range the higher the risk the larger the difference between best and worst caseestimates
Governance the higher the risk, the more attention and more often the meetings Sponsors andSteering Committees should provide to the project and project manager; and
Contingency Plans the higher the project risk, the greater the need for a Contingency or Get outplan.
When planning
projects, it pays to
be paranoid. In other
words, plan for the
worst and hope for
the best.
-
7/28/2019 Agile PM Primer 2008
12/18
Agile Project Management A Primer
11 2007
Pro-active Risk Management revisitedAll High Risk factors should be documented with a Risk Memorandum which stateswhat the risk is and what mechanisms are available to manage the risk. The Risk Memomustbe reviewed with the Project Sponsor.
Risk Memos typically identify:
what is the risk factor?
what is its impact should it remain unresolved?
what can be done to manage or minimize the impact of the risk?
what is the fallback or Contingency Plan should the risk remain an issue?
Develop task list/features listThe process of task listing should use the organization's product development framework (often called a
methodology), if one exists. If Agile development approaches are being used, the relevantCompoments/Features identified during this process. The following process should be applied to developingtask lists:
using the product development cycle, the team extracts a "first-cut" list of the tasks contained inthe product development cycle that are relevant to the project being planned. If there is no
organisation standard P.D.C., then the team should brainstorm a "first-cut" task list
using brain-storming, additional tasks not contained in the product development cycle but that arerequired for the project are listed
the "first-cut" list should be broken into smaller tasks and reviewed by as many technical expertsas possible.
Project :
PRODUCT/SYSTEM RISKS LOW MEDIUM HIGH
1. Overall system/service/product Simple Average Complex2. Logical data (include. files) Simple Average Complex3. I/O and enquiries or organisational impact Simple Average Complex4. Interfaces to other systems/services/products Simple Average Complex5. Functions and processes Simple Average Complex6. New business procedures/alterations None Some Extensive7. Stability of requirements Stable Average Unstable8. Performance requirements (including quality) Low Medium High9. Technology requirements Simple Average Complex10. Level of technical innovation None Some InnovativeTEAM RISKS LOW MEDIUM HIGH
1. Intrinsic team skills (general skills) High Average Low2. Relevant skill level with application/product Extensive Some None3. Project manager experience Extensive Some None4. Project staffing level 1 - 5 5 - 10 over 105. Use of contractors/part-time members None Some Extensive6. Project development length 1 - 3 mths 3 - 6 mths Over 6 mths7. Schedules/deadlines Flexible Firm Fixed8. Priority of project for team High Average Low9. Team experience with hardware/software or technology Extensive Average Some10. Project team physical/support environment Excellent Average Poor ENVIRONMENT/TARGET RISKS LOW MEDIUM HIGH
1. Level of client/user support High Medium Low2. Client experience with product/system Extensive Some None3. Client Project Sponsor support High Medium Low/None4. Impact on client operations (new technology, policy,etc.) Low Medium High5. Client/business expert participation Full-time Part-time Ad-hoc6. Key (Critical and Essential) stakeholders 1-2 2-10 Over 10
OVERALL PROJECT RISK LOW MEDIUM HIGH
NEVER start
a project without an
agreed fallback or
Contingency Plan.
-
7/28/2019 Agile PM Primer 2008
13/18
Agile Project Management A Primer
12 2007
The following tips are also suggested during the task listing process
do not confuse task listing with scheduling - the sequence of execution of the tasks is consideredduring scheduling - task listing can be done as a free-form brainstorm;
do not list tasks in phases that are beyond the phase or event currently about to be commenced.For example, in the project is about to commence the Product Requirements phase only list the
tasks for that phase in detail; and
check the task list with as many people as possible. A missed task is additional effort and couldmean that the project will not meet the agreed Business Case and schedule.
As the task list is the basis for detailed estimation, the process of task listing should be given as much careand effort as possible.
All these processes are undertaken using micro-planning concepts that assume that planning and re-
planning are a continuousactivity throughout the project development cycle.
Change is inevitable in contemporary projects so re-planning is inevitable. Your projects Business Case mustbe maintained as it is a living document.
Undertake project sizing/estimatesProject estimation involves task-based estimates using Wide-band Delphi and phase-based estimation - whichuses percentages across the various phases of the product development cycle.
The following process should be applied to for Wide-band Delphi estimation:
undertake an analysis of the projects Quality expectations (via the Quality Agreement) and a fullRisk Assessment before you estimate;
each member of the planning session estimates the initial phase task list using raw effort estimatesi.e. one person in actual effort;
estimates are derived for three ranges - Best Case where everything goesbetter than expected - Likely Case where things go as expected - Worst Casewhere things go worse than expected;
the members of the planning session then share their estimates and discuss
any major areas of difference in each estimate
after the discussion, if there is no consensus, any outriders are excluded andthe remaining estimates in each range are averaged.
A single point estimate is derived either by:
Expected = Best Case + 4 x Likely Case + Worst Case/6
using an informal risk assessment for each task, low risk tasks are scheduled at the Best Case,medium risk tasks are scheduled at the Likely Case and high-risk tasks are scheduled at the WorstCase.
Task-based estimation should be used only for the phase about to commence. Total project estimates arederived using phase percentages. For example, assuming Product Requirements is 25% of the total productdevelopment cycle then the total of the task-based estimates for Product Requirements are multiplied by 4 toderive a total product development effort.
What is also important to remember is that the earlier the estimate is made, the more inaccurate it will be.
An estimate
undertaken by one
person is WRONG.
The more people
involved in
estimating, the more
accurate the
estimate.
Evaluate
Package
Evaluate
Package
Determine
Test Plan
Determine
Test Plan
Review
Vendors
Review
Vendors
Convert
Test Data
Convert
Test Data
Obtain User
Group List
Obtain User
Group List
Contact
User Sites
Contact
User Sites
Select
Site Visits
Select
Site Visits
-
7/28/2019 Agile PM Primer 2008
14/18
Agile Project Management A Primer
13 2007
Production Support Estimates
Based on our own research and that in the construction and engineering industries, you should allow a 1:1ratio for product development and support. This is independent of the estimated product life-cycle.
Develop project scheduleThere are three basic steps in developing a project schedule.
The first is to develop a network or PERT diagram that shows the tasks and their dependencies. There are twocommon types of dependencies - Finish-to-Start where one task must finish before another can start - Start-to-Start where one task can start after some time lag after another. These dependencies can either be a
deliverable or a person.
The second step is to factor in duration based on the estimated effort for one person to complete each task.Duration or elapsed time must take into account other non-project activities that the person must also handleduring each day.
At this stage the Gantt chart can be produced and the initial critical path indicated. The critical path is thelongest path in duration through the network.
The final step is to allocate actual resources to your tasks and adjust the time-line.
With Agile development, this process is more likely to be undertaken on a white-board.
Resource AssumptionsWhen you allocate people to your project and tasks, make sure that you clearly state what assumptions you
are making i.e. skills, experience, attitude and so on. The more specific you are the more likely you can avoidsubstitution of less experienced people.Stakeholder CommunicationYou should develop specific communication strategies for all your stakeholder groups. For Criticalstakeholders, communication should be face-to-face; you must gain their sign-off for any change in theBusiness Case and they are fully involved in the RAP sessions. Essential stakeholders should be dealt withface-to-face if possible. Interested Parties should receive regular updates such as project status reports,newsletters and road shows.
Task A Task B Task D
Task C
This diagram indicates the
sequence of undertaking tasks.
The box indicates a task and the
line indicates a dependency. In
the diagram, Tasks B and C are
dependent on Task A finishing
and Task D is dependent on Tasks
B and C finishing.
Critical Path
The effort has been converted to
elapsed or calendar daysallowing for non-project tasks.
The critical path is the longest
path through the network.
Task A
8 hours effort
2 days
Task B
12 hours effort
3 days
Task D
4 hours effort
1 day
Task C 8
hours effort
2 days
-
7/28/2019 Agile PM Primer 2008
15/18
Agile Project Management A Primer
14 2007
Project Business CaseThe Business Case is the managerial contract between the information products development group andclients. It is developed during the planning session from the project concept or initiation documents.
It should contain the following information:
project scope and objectives;project stakeholders and related projects;
project benefits;
project costs (development and support);
project development strategy;
project risk assessment;
risk memorandums;
estimates;
change management;
schedules;
any major assumptions and constraints; and
quality agreement.
The Business Case should be agreed to and formally signed off by the Project Sponsor or Steering Committeeand all critical stakeholders. The Business Case cannot be altered without prior agreement from the ProjectOwner/Steering Committee and key stakeholders and related projects.
The Business Case would be associated with technical Feasibility Study document which would containoverviews of the product's requirements and initial technical solutions. It should always be produced by aRAP session and is the by-product of the RAP session.
Project TrackingProject tracking should occur at least weekly and should involve a team-based review session.
The primary focus of the tracking session is to determine whether the project is keeping to the agreedBusiness Case and the project schedule.
The team should be using a PC-based scheduling tool Task Form to enter the actual task effort whichprovides a visual feedback as to the progress of the tasks.
Project tracking should also accumulate actual progress versus estimated progress and actual effort (costs)
versus planned effort (costs). This information can also be entered via the Task Form in the PC-basedscheduling tool.
The Table Tracking view in most scheduling tools can produce the Gantt chart shown above. Tracking of thequality of the technical deliverables should be undertaken via the use of Inspections or Quality Reviews whichare peer-based quality assurance techniques. Until a task's deliverables have been reviewed technically, it isnot wise to declare the task complete.
However, a team meeting is always the most effective tracking process as it can discuss soft factors that maybe affecting success.
Individual GANTT/Actual progress
Week 1 Week 6Week 2 Week 3 Week 4 Week 5
Mary Jones
Task A
Task C
Task B
-
7/28/2019 Agile PM Primer 2008
16/18
Agile Project Management A Primer
15 2007
Project Reporting & ReviewReports should be forwarded to the Project Sponsor, Steering Committee and key stakeholders on a regularbasis. There should also be specific phase-end reports produced when major technical milestones such ascompletion of Product Requirements are reached.
Project reporting should focus on the Business Case and the associated project schedule. The Business Case
focus ensures that the project management process concentrates of the management concerns of budget,deadlines, resources and so on.
The project report should include the following details:
has there been any variation in the expectations of project success (Page 3)?
has there been any variations in the Business Case (incl schedule) since the last report;
if so, is there an updated Business Case for review and approval;
have the stakeholders reviewed the changed Business Case;
what are the key issues for the Project Sponsor (Steering Committee) to action;
any key milestones, deliverables produced during the reporting period; and
any major future developments expected in the next reporting period.
The Project Report should be treated as a key mechanism for keeping stakeholders aware of the progress ofthe project.
The Project Report should also show the actual progress in the last period against theplanned using a GANTT report and the Costs Summary report.
Technically-oriented reports such as detailed product designs, technical models and soon should be forwarded to relevant technical support people in the organization.
Finally, the project reporting framework should reflect the projects expectations ofsuccess (Page 3). For example, if Quality is mandatory for the product and Budget isflexible, then the project report should focus on QualitynotBudget.
In addition, the project reporting cycle should be driven by the Project Risk. If you are undertaking a High-risk project, you should have a more frequent reporting cycle than one for a Low risk project
Project Success and Tracking An Agile ViewThe Success Criteria (Sliders) discussed on Page 4 should drive the tracking of a project.
Project Change ManagementIt is to be expected that the initial Business Case and associated technical requirements will be subjected tochanges during the product development cycle. There are two types of changes;
internal - changes arising from within the project team;
external - changes arising from stakeholders outside the project team
Any change to the initial Business Case must be subjected to formal recording, analysis of the impact and, ifrequired, a re-planning session including update of the Business Case and project schedule.
What is critical to note is that the Business Case is a living document. It will change many times during aproject and the Project Sponsor must approve all changes to the Business Case.
Project SponsorThe Project Sponsor is themost important person in the project management world. Thisperson is the person who must have the organizational powerand thefinancial delegationto act quickly and decisively in the overall governance of the project. The main roles ofthe sponsor include:
the assistance to projects in an 'out-of-control' situation;
assistance in the development, review and approval of the project BusinessCase and any changes;
review and approval of changes to project staffing, schedule, deliverables,priorities, etc.;
No Sponsor,
No Start. Research
by our group and the
Standish Group, in
the U.S., show that
the effectiveness of
the sponsor is one of
the critical factors
in project success.
What senior
management really
want to know is are
there any nasty
surprises in the
project. If so, what
can they do to assist
in resolving the
issue.
-
7/28/2019 Agile PM Primer 2008
17/18
Agile Project Management A Primer
16 2007
decision of major priority of releases/deliverables;
high level approval of interim deliverables;
review of overall project quality requirements;
interface to other areas impacted by project;
resolution of inter-project boundary issues;
approval of project development strategy;
management of the benefits realisation; and
oversight of the support and maintenance of the projects outputs.
Project Steering CommitteeThe Project Steering Committee represents, at an executive-level, the criticalstakeholder groups in the overall governance process. While the Project Sponsor is thesingle point of accountability for the project, the steering committee members expandthe governance process by undertaking the same roles as the sponsor.
In particular, the Steering Committee provides a court of disputed returns. Forexample, if there is conflict between two different stakeholder groups involved in theproject, the Steering Committee would be able to resolve the conflict at an executive
level.
In effect, the Project Sponsor should be considered as the executive Project Manager inthe sense that he or she makes all the critical management decisions for the project.
Organizational Change ManagementAll projects involve changes to organizational business process, personal power and broader culturalconcerns.
Agile project management reduces the impact of these changes through active involvement of those people
impacted by the change. However, in many projects, meeting the challenges of the broader cultural impact ofthe project require specialist cultural and sociological skills that most project managers do not possess.However, one powerful tool is to examine clinically the wins and losses faced by stakeholders if the projectsucceeds.
wins look for ways of maximizing these;
losses look for ways of minimizing these.
Project ChecklistThe following checklist provides the essential questions for reviewing project plans and project development::
is there a clear statement of the project's scope and objectives?
is there a statement of stakeholders and related projects?
has the appropriate level of project sponsorship been obtained for the project?
are the relationships and services involved with the stakeholders and related projects documented?
are benefits and costs clearly identified and the assumptions involved in the calculationsdocumented?
is there a benefits realisation plan, which identifies how the benefits are to be realized?
is there a statement of which stakeholders are involved in the realisation of the benefits stream?
is there a clear statement of the quality expectations for the project?
is the project's development strategy/events/scenarios identified?
are the risks (business and project) involved in the project identified?
is there a risk containment strategy included?
are the task lists realistic and have relevant experts checked them?
are estimates, costs and benefits stated as a series of ranges (best, likely, worst)?
has a project schedule been created?
are all relevant resource assumptions included?
have key stakeholders agreed to the project's Business Case?
have any policy, staffing or legislation impacts been evaluated?
is there an estimate provided for on-going support and maintenance of the projects outputs?
The Bag of
Money and the
Baseball Bat Test.
The person who is
sponsoring the
project must have
the right level of
financial delegation
(Bag of Money) and
the organisational
power (Baseball Bat)
to make decisions
quickly.
-
7/28/2019 Agile PM Primer 2008
18/18
Agile Project Management A Primer
17 2007
Rough Rules for VeteransThese rules summarize bitter lessons learnt by many battle-hardened veterans:
Most projects that fail had failed before they started;
These projects were given fixed deadlines before any estimates, requirements, quality requirements and
resources were determined and because of this were never planned properly or adequately supported bysenior management.
It is extremely difficult for a Project Manager to stop a project that is failing;
People in a project that is failing will become obsessed with working harder as a result of the energy and egothat they have already committed in the project. Planning and quality begin to be seen as luxuries that the
project cannot afford.
If you cannot stop a project - it is failing;
No matter how close the deadline, planning will always pay back the time required. The "lemming rushsyndrome" switches in and people start denying the reality of the project and start believing that workingharder can substitute for working smarter.
Planning is work - working is not planning;
It is easy to substitute hard work for clever planning and communication.
It pays to be paranoid when planning a project;
Plan for the worst and hope for the best .. there are more risks in your project than you can ever imagine.
A well-managed project is generally less exciting than a badly-managed project;
The adrenal rush of a project forced to meet a deadline or to solve a difficult problem under pressure is thestuff of heroes and heroines.
If nothing has changed in your project - get paranoid !!!!
Change is normal in projects. If there have not been any changes to your project [scope, objectives,
stakeholders, risk levels and so on] then either you have not been communicated to by your team oralternatively you have been "set up".
Your stakeholders are your best friends or worst enemies you decide at the beginning
Getting buy-in from your stakeholders is easier than ignoring them and getting them to buy-out.
Dont own the project own the process
When you cross the line and start owning the project, you begin to alienate stakeholders; you marginalizethe sponsor; you lose perspective and, most importantly, you become too protective. All projects belong to thesponsor and stakeholders. You are the person who is responsible for making it happen. What you can getprotective about is the process of project management and your team.