10/23/2015 4:14 am 1 identifying a project in trouble & replanning mpug 111208 moritz farbstein...

04/20/23 02:52 1

Identifying a project in trouble & replanning

MPUG 111208

Moritz FarbsteinSenior Consultant

12 November 2008

Identifying a project in trouble & replanning 04/20/23 02:52 MPUG 111208 2

Senior Policy

• Deliver what you promise.– Corollary: Do not promise what you know you cannot deliver.

Quality - The degree to which a product or service meets the requirements; conformance to requirements.

Quality Plan - Initial quality considerations should include:

Quality

Quality Goals Quality Reviews

Quality Objectives Quality Activities

Quality Organization Quality Processes

Quality Roles Quality Standards

Quality Responsibilities Quality Procedures

Quality Resources Quality Tools

Quality Key Events Quality Measurement

Periodically audit the Project and the Project Plan to the Quality Plan.


Conformance to Requirements

• Many project failures can be attributed to problems with Requirements (unspecified, unclear, changing, etc.)

• Good requirements do not come from a tool, or from a customer interview. They come from a repeatable set of processes which take the project from the early idea stage through to the creation of an agreed-upon project and product scope between the customer and the developer.

• And continuing throughout the Software Development Life Cycle, requirements should be traced to ensure that conformance occurs in all aspects of Design, Development, Test, Documentation, User Acceptance, Maintenance.


The Triple Constraint

• A project manager faces a complex challenge essential to success: delivering the agreed-on project product or services within the time and cost constraints. Meeting the time constraints, not exceeding the cost constraints, and delivering what was promised are all essential requirements of project success.

• The three requirements are grouped as a single function because they are interdependent. A change in one affects the others, and all three must be satisfied simultaneously for the project to succeed.

• Balancing the three requirements related to Delivery, Time, and Cost is sometimes called managing the Triple Constraint.

• Delivery, time, and cost requirements take the form of project Performance and Quality specifications (often called “Scope”), the project Schedule, and the project Budget.


HOW IT’S HOW IT’S SCOREDSCORED

Client

Staff Mgmt

HOW IT’S HOW IT’S PLAYEDPLAYED

Control

Plan Manage

THE GAMETHE GAME

Scope

Schedule Budget

The “Game” of Project Management – Goal: Win-Win-Win on all Points


Manage to the Triple Constraint

To manage to the triple constraint, you must:

• Define the project’s purpose, scope, approach, constraints, work products, priorities, and so forth.

• Create a plan that correctly interprets the project definition, is credible, realizable, and in sufficient detail to monitor & measure effectively.

• Monitor the project’s performance against the plan.

• You must define the measurements you use for controlling the project. Without these measurements, you have no way of knowing where the project is currently headed, how far off course it is, or what action to take to get it back on course.


Project Purpose and Priorities

• During project execution, all project team members should know the priorities attached to each element of the triple constraint - delivery (scope), time (schedule), cost (budget).

• Two aspects are critical:

– “What is the compelling event that caused the client to request this work?” (i.e. goal, purpose, objective)

– “What priority is placed on delivery, time, and cost by the client?”

• Every project decision is considered in the light of its consistency with, and impact upon, those priorities.


Quality of a Project Plan

• The Quality of a Project Plan is the degree to which the plan enables management to the

Triple Constraint.


What is a “Troubled Project?”

• A situation will escalate to troubled status when one of the major stakeholders (customer, supplier, sponsor, etc.) can no longer tolerate the situation—in other words, when the variance trends have exceeded acceptable levels of tolerance.


When is a Project in Trouble?

• When one or more of the Triple Constraints are

– Out of control (possibly a subjective measure)

– Showing an adverse variance from expected performance

– Outside the limits set in the Quality Plan (an objective measure if it exists)

• How does one judge when a project is in trouble?

– “Judgment” is measured by the ability to evaluate relative importances.

– The basic process of this analysis is to gather information about delivery (scope), time (schedule), cost (budget) and evaluate the relative importances of the data thus found. It may not matter that the project is out of scope, over schedule or over budget – only by comparing this information with project priorities, management directions, project objectives, risks, issues, contractual rewards & penalties, and so forth can a valid judgment be derived and an agreement reached.

• There may be legitimate reasons to cancel a project; this alternative should not be overlooked.


When is a Project in Trouble? (reactive)When is it Predicted to Be in Trouble? (proactive)Some Triple Constraint Considerations

• Delivery / Scope (includes Quality and Performance)

– Missed deliverable or predicted miss on deliverable

– Scope creep

– Change Management non-existent or out of control

– The quality of what was delivered was not what was expected

– Defects are high, there is a backlog of open defects

– A named risk actually occurs (a risk may impact Delivery, Time, &/or Cost)

– Issues are not being identified and addressed

– Low morale, lack of teamwork• “Morale” = “Production” – morale drops when production drops and morale increases

when production increases

– No clear direction exists for where the project is headed or when it will get there

– Escalation of issues is not working


When is a Project in Trouble? (reactive)When is it Predicted to Be in Trouble? (proactive)Some Triple Constraint Considerations• Time / Schedule

– Schedule variance; Schedule Performance Index

– Missed milestone or predicted miss on milestone

– Resource over-allocation; resource flow variance metric

– Unrealistic commitments

– Too much (involuntary) overtime

– Finish Dates keep pushing out

– Frequent and extensive replanning

– The amount of work left to do on a task is more than the assigned resources can accomplish before the expected Finish Date

• Cost / Budget

– Cost variance; Cost Performance Index

– Over budget or predicted overage on budget

– External changes (contracts, management decisions, vendor changes)

– Change Requests directly impact the Budget (e.g. hardware requests)


When is a Project in Trouble?Additional Considerations

• Talk with the (previous) project manager.

• Talk with the project team, including the executive sponsor.

• Is the team competent enough in running a project to know where they really are?

• If the team knows what they are doing then do they actually believe the project is on track?

• Is there an agreed project purpose and project plan? Has it changed?

• Are the key dates achievable and consistent?

• Are external inputs into the plan on target?

• Does the high-level structure of the plan appear logical?

• Is the resourcing realistic?

• Are there any unrealistic constraints on dates?

• Do the Project Manager or team members have other responsibilities besides this project?


Death by Meeting

• Another indicator of a project in trouble – endless and/or nonproductive meetings.

• Death by Meeting: A Leadership Fable...About Solving the Most Painful Problem in Business

by Patrick M. Lencioni

Copyright 2004, Published by Jossey-Bass, a Wily imprint, San Francisco, ISBN: 978-0-7879-6805-2

• Does it really need a meeting, or can you just get an answer over the phone?


Check and Re-Check Your Focus

Periodically ask these questions. If your answer to one or more of them is “No,” there is a high risk that the project is in trouble.

• Is the agreed-to project scope still the basis of work?

• Am I maintaining a correspondence between what is happening on the project and what the three constituencies (client, staff, and management) expect and need?

– Am I keeping expectations in balance?

– Am I meeting management expectations?

• Does the Project Plan correspond to the work being done by the project team?

• Does the Project Management Plan still represent the path to success?

• Are issues outstanding beyond their agreed-to resolution date, are risks not mitigated or avoided, or do changes remain outstanding (either not agreed upon and incorporated in the plan, or under discussion)?

• Do the project reports provide an accurate, succinct account of the project, and are they a basis for informed decisions and actions?


Project Management Tips

• The closer one is to the project, the shorter the period of time used to report and manage. For example, a line manager might be gathering data, reporting and managing hourly or daily; a local executive may be reviewing the project weekly; a remote executive may be reviewing the project monthly or quarterly.

• When MS Project is used as the source of all project planning information, MS Excel can be used to capture metrics. Excel can consolidate data from Project and build a Dashboard.

• It helps if all projects and all project managers use the same naming conventions, formats and templates.

• The people doing the work must be actively involved in scheduling it.

• Do not focus solely on problems - Recognise team members for jobs well done and celebrate successes.

• Whenever new information crosses your path, think “Who else needs to know this?” and make sure they do.



• Run the Project Plan through the formal Approval Process.

• Use a formal process & automated tool for Requirements that can produce a Requirements Traceability Matrix (Req->Design->Code->Test).

• Hold a post mortem to solicit input for lessons learned.

• Insist that people do their own jobs. When they don’t, keep telling them until they do.

• Choose your battles.

• Do not bring “problems” to Management and ask them to solve them; only bring them “solutions” to which they can say either “yes” or “no” or take some recommended action.

• Management must CARE about the people doing the work. The opposite of caring is slavery.

• Enforce the correct and appropriate process and methodology, but don’t allow it to stop the work. This will always be something that must continually be balanced. Build process and methodology training into the project plan if at all possible.



• Action Items must always have the Name of who will do it and the Date for when it is due. Review AI’s regularly and get them Done.

• Look, Don’t Listen! If they really knew what was actually wrong they would already have fixed it.

• It may not be just “one” problem and “one” solution. It may be more than one problem and more than one solution.

• The work to recover a troubled project is a project all by itself. The rescue project has a sponsor, an approval, a start, an end, resources, deliverables, schedule, cost, etc. A recovery project must be run with much tighter control than the original project, or risk a second failure.

• Verify that all work reported as "done" is in fact completed. (“Not Dones,” “Half Dones,” “Backlogs”)


Being “Reasonable”

• You succeed when you are unreasonable. You neither give nor accept excuses. You insist on success.

• Reasonableness is “faulty explanations.” When you agree with faulty explanations, you are too reasonable. If you agree with faulty explanations, you agree to fail. Excuses, justifications and reasonableness produce nothing.

• The most important thing you must be unreasonable about is Down Statistics. Example: the testing schedule calls for completing 50 tests per day. Yesterday only 40 tests were completed. Today, being unreasonable, you must demand that 60 tests are completed. The alternative is to go over schedule; how much contingency is built in?

• Finally, if you are reasonable, your project will likely fail; there are too many things that can go wrong, and only one way to go right (i.e. follow the project plan and meet the milestones,) because, if your plan is like most plans, it is predicated on everything happening on schedule. Murphy says that your schedule will use up all built-in contingency time before all the contingencies have occurred.


Cycle of Action

• Create [Start]

• Survive [Change]

• Destroy [Stop]

Control is defined as the ability to start, change and stop something.


The Project Life Cycle

• Initiate

• Plan

• Execute

• Monitor and Control

• Close-Down


The Weekly Control Cycle

The weekly control cycle is the basic foundation for project control activities. Prioritize your week around completing these tasks:

• First, start in control with a sound plan

• Then, on a weekly basis:

– Collect and review project data

– Post actuals and calculate variances

– Evaluate status (using all available information)

– Control risks, issues and changes

– Focus on taking corrective action on variances, issues and problems

– Manage acceptance of deliverables

– Update the master plan as appropriate, or re-plan

– Provide a status report with quantified status of delivery, schedule and budget

– Meet regularly with the team


Project Office and Program Management Office

• Establish a Project Office and/or a Program Management Office.

– A project office (PO) is a team that is brought in on a large project or multi-project program to assist the project director and management team with project startup, control, and monitoring activities.

– A program management office (PMO) is a governance body for managing a program. Typical program management office responsibilities are to supervise and coordinate across multiple projects:• Project planning

• Measurement, monitoring, tracking, reporting

• Resolve, or raise and elevate, issues and risks that affect more than one project

• Change Management

• Quality Control (e.g. adherence to Policy and Standards)

• Manage achitecture interdependencies

– When a program management office scope expands to the enterprise level, it is often referred to as an enterprise program management office (EPMO). The purpose of an EPMO is to provide a strategic perspective to align with the business goals.


CSC M5 Offering Addresses The Following Management Disciplines

• PMO: IT or Business Management Offices ranging from department-level to enterprise level.

• Portfolio: Management techniques and tools for selecting the “right” project, application, or infrastructure investments.

• Demand: Management techniques and tools for managing day-to-day application and infrastructure service requests.

• Complex Program: Experienced practitioners available to manage the organizations most difficult initiatives.

• Project Recovery: Swat team services designed to rescue troubled projects and to establish controls for preventing future runaway projects. Can be implemented individually or collectively

CSC M5

Complex Program

Management

Project Recovery

Management

PortfolioManagement

PMOManagement

Demand Management


ReplanningJust the same as planning, only doing it again

• Investigate where the project stands and where it is headed.

• Assess and re-plan the project if it has gotten off track.

– Review all outstanding tasks and requirements, then sort them into these categories:• 1. Must have

• 2. Nice to have

• 3. Cannot do yet

• Reset everyone's expectations.

• After resetting project goals and expectations, focus on delivery. Get something that can be completed actually completed. Project work should not stop during replanning, although it may be reprioritized, and temporarily suspended in extreme cases.

• Publicize the fact that something got done. Here is where Project Management crosses with Public Relations – don’t let everyone think that “all is lost” when it is not.


ReplanningJust the same as planning, only doing it again

• Plan is revised, if required, for changes of scope, budget, schedule, risks, adverse performance variances, and so forth. Plan revision should be assessed with approved change requests.

– Re-Assessment can be triggered by events such as Change Requests, delays in starting the project, scope changes, start of a life-cycle phase, extending the detailed plan, contractual changes, cost or budget changes, missed milestones, risk occurrence, risk mitigation failure, adverse variances of Earned Value metrics, failure of a Proof of Concept, periodic required re-assessments or audits, major resource changes, etc.

– In other words, replanning is not done only to handle a project in trouble, but also for any significant events that may affect the Triple Constraint.

• A project in trouble enough to revise the project plan should be managed by the change control process.

• Develop several alternatives from which management can choose.


Alternatives

• Reduce scope

• Phased releases & reorganization of deliverables

• Add resources

• Work overtime

• Pay overtime and/or bonuses

• Reward success, penalize failure

• Purchase and use tools

• Improve and/or enforce processes

• Improve team dynamics (i.e. communication)

• Cancel part or all of the project

• Revise the business case (increase the budget, change the scope, etc…)

• Heroics may work this time, but are heroics repeatable, and at what cost?


How to Present Alternatives to Management

• Use a form such as:

– Situation• Name the situation, problem, issue, etc. and why it is such.

– Data• Present ALL the information that management would need to make a “Yes or No”

decision. This would be all the pro’s and con’s of the situation and of the various solution alternatives, the Triple Constraint data, the priorities, the contractual commitments; whatever information is needed on which to base a decision on how to proceed. Use the Triple Constraint model to describe how things must change.

– Solution• Recommend a solution to which Management can say either “Yes” or “No.”


Replanning• Work Breakdown Structure (WBS)

– Tasks, deliverables, resource assignments

• Dependencies

– Task predecessors & successors, critical path, priorities

• Schedule

– Milestones, timeboxes, put vacations & holidays into the Calendar

• Organization

– Roles, responsibilities, accountabilities, reporting relationships

• Staffing

– Number & type of personnel broken down by role and by time period

• Budget

– Time-phased budget baseline

• Payment Schedule – Sponsors, vendors, subcontractors

• Acquisition Management - Solution selection and contractor oversight


Earned Value Management

• With a complex project, obtaining a single view of cost and schedule is virtually impossible without a metric that combines the impacts of cost, schedule, and work performed to the current date. The Earned Value technique is such a metric, and it provides a single view of cost and schedule over time.

• Earned Value is a technique used to compare work planned with work performed. Each product is given a budget and a completion date. When it is agreed that the product is complete, its value (planned cost of work to complete it) is earned.

• Earned Value, then, is the budget (planned cost) for a completed piece of work. [It can also be measured as the work (labor hours) to complete.]

• The Earned Value is compared to the Actual Cost of completing the work. If the budget is exceeded, the result is an unfavorable cost variance to the amount of overrun. If the work takes longer than planned to complete, an unfavorable schedule variance occurs, measured by the value of the work not yet performed.


Sample of Earned Value


Example (MS Project 2007)


Example


Example (CSC)


SharePoint Server 2007 Dashboard Web Parts


SharePoint Web Parts


Project Server 2007 Reports


Calculate the Burn Rate

• The Burn Rate shows how much effort is needed going forward to finish on time, expressed as a percentage of remaining planned hours:

Burn Rate = [EAC – ACWP] / [BAC – BCWS] (in labor hours)

• EAC (Estimate at Complete) less ACWP (Actual Hours to Date) [Actual Cost of Work Performed] equals the number of actual hours needed to finish the project. EAC is calculated as ACWP divided by the Cost Performance Index. In the denominator, BAC (Budget at Complete) less BCWS (planned hours to date) [Budgeted Cost of Work Scheduled] equals the remaining number of budgeted hours, i.e., the remaining planned staffing. When this ratio is greater than 1.0, it means that planned staffing is insufficient to get all work done before delivery date.

• Cost Performance Index (CPI) is the ratio of the earned value (EV) to the actual cost (AC). CPI = EV ÷ AC. A value equal to or greater than one indicates a favorable condition and a value less than one indicates an unfavorable condition.

• In MS Project, set Standard and Overtime Rates for all Resources to 1 in order to get EV metrics in hours instead of $’s.


References• Earned Value Management

– http://evm.nasa.gov/

– https://acc.dau.mil/evm

– http://www.microsoft.com/office/showcase/earnedvalue/default.mspx

– http://office.microsoft.com/en-us/project/HP010342581033.aspx

– http://office.microsoft.com/en-us/project/HA010211791033.aspx

– http://office.microsoft.com/en-au/project/HA101567921033.aspx?pid=CH100666601033

– http://www.projectperfect.com.au/info_earned_value_management.php

– http://www.dekkerltd.com/

– http://www.deltek.com/products/wInsight/

– http://www.deltek.com/products/cobra/default.asp

– http://lmrsolutionsgov.wordpress.com/2008/03/05/applying-earned-value-analysis-to-your-project/

– http://www.decisionedge.com/DecisionEdge-EarnedValueManager.html

– http://www.quantumpm.com/earnedvaluemanager.aspx

– http://articles.techrepublic.com.com/5100-10878_11-5030576.html


References• Enterprise Project Management

– http://office.microsoft.com/en-au/epmsolution/FX101935291033.aspx

• Managing Costs

– http://office.microsoft.com/en-us/project/CH100666641033.aspx


• Creating a Budget


• Microsoft Project Most Valuable Professional Page

– http://project.mvps.org/

• Microsoft Project 2003 Add-in: Create PowerPoint from Project

– http://www.microsoft.com/downloads/details.aspx?FamilyID=5a4d6d5b-069a-401c-9de1-440546836b85&DisplayLang=en

• Microsoft Excel Services (dashboards, SharePoint, Project Server)

– http://msdn.microsoft.com/en-us/library/cc539928.aspx

• SharePoint Web Parts dashboard generation with Project Server 2007

– Go to “Business Intelligence” on the Project Server 2007 SharePoint Help Menu


References

• Create a visual report in Microsoft Project 2007 (export data to Excel or Visio) [Report->Visual Reports…]

– Enter “Create a visual report” in the Help search box

• Status Stoplights with Microsoft Project

– http://www.projectperfect.com.au/info_stoplights_in_microsoft_project.php

• Microsoft Project 2003 Analyze Timescaled Data Wizard

– http://articles.techrepublic.com.com/5100-10878_11-5030581.html

– http://office.microsoft.com/en-us/project/HP430079291033.aspx

• Microsoft Project 2003 Reports in Access

– http://www.projectperfect.com.au/info_msp_reports.php

• Microsoft Project 2007 Save to Excel Pivot Table (or other formats)

– Enter “Export wizard” in the Help search box

– http://safari.ibmpressbooks.com/9780735623057/ch12lev1sec5#ch12lev1sec5

• Quality Management - The Deming Cycle

– http://en.wikipedia.org/wiki/Shewhart_cycle


References• Dashboards

– http://www.enterprise-dashboard.com/

– http://msdn.microsoft.com/en-us/library/aa164875(office.10).aspx

– http://www.spmn.com/pcpanel.html

– http://store.bamboosolutions.com/ps-102-2-bamboo-project-management-suite.aspx

– http://www.decisionedge.com/landing_microsoft_earnedvalue.html

– http://mcpmag.com/features/article.asp?EditorialsID=2405

– http://www.jedox.com/en/enterprise-spreadsheet-server/excel-olap-server/palo-server.html

– http://processdash.sourceforge.net/

– http://www.epmsolutions.net/services/server_reporting.html?gclid=CNquqoK2mJUCFQOeFQod7kz9gQ

– http://www.decisionedge.com/microsoft_decisioncharts_msolanding.html

– http://dashboardspy.wordpress.com/

– http://www.projectlink.co.za/systems_project_dashboard.aspx

– http://www-03.ibm.com/press/us/en/pressrelease/24194.wss


References

• Business Analysis and Project Requirements

– Determining Project Requirements, Hans Jonasson, Auerbach Publications © 2008

– Guide to the Business Analysis Body of Knowledge, International Institute of Business Analysis, www.theiiba.org


Identifying a project in trouble & replanning

Moritz Farbstein

Senior Consultant

[email protected]

MPUG 111208

10/23/2015 4:14 am 1 identifying a project in trouble & replanning mpug 111208 moritz farbstein...

Documents