How To Manage Project Delays

Project delays are integral part of day to day deliveries, however not affordable.

Parkinson's Law, speaking to effort, tells us that "work expands to fill the space allotted".
Murphy's Law, speaking to uncertainty, tells us that "whatever can go wrong will go wrong, and most likely at the worst possible time".

Such realities are faced by all project managers. No matter how much time you have for a project, it will likely be consumed, and no matter how well you plan, eventually you will always be faced with the "unexpected".
So, if work always expands to fill the space (time) allotted, and whatever can go wrong will go wrong, the only thing you can do is to Be Prepared. 

This post will try to highlight few techniques to Prevent Delays (Before Delay Occurs) and Fix Delays(Post Delay Occurs).

Preventive: Technique to Prevent Delays:

Catch It Early & Track Vigilantly

• Unless you have some magic, ideal way to handle project delays is to predict them happening and countering whatever may be the cause, avoiding any interruption altogether.
• Keeping yourself constantly aware (Have Daily Team Meetings) of the project schedule and keeping in close contact with your team will enable you to notice a delay as soon as it happens.
• Keep a close eye on upcoming deadlines and priority assignments. If you notice that some deadlines are falling behind or a specific task is not as close to completion as it could be, ascertain what is causing the holdup and resolve it quickly to avoid any further setbacks.
• Keeping quick attention and prompt action will get the project back on track as close the original deadline as possible.

Prioritize

• Review tasks & priorities assigned to team members. 
• Project Risk are always high during the start.
• Thus always prioritize project assignments, moving any that are especially time sensitive to the top of the list. 

Record Changes or Scope Creep

• Obtain final requirements & get a sign-off on the functional specification before starting construction
• Never accept changes unless you have done a complete impact analysis on each of the baselines – Time/Cost/Quality
• The best way to do so is by creating a change control plan that outlines the proposed changes, review, approval and implementation.
• Any change impact causing project delays should advance project delivery timelines or reduce in scope.

Predictable Delays - Document Project Delays Risk & Have Mitigation Plan Ready:

• Predictable delays (those deemed likely by circumstance and experience) can be factored into the project via a documented risk management plan. 
• When Risk plan is prepared, risks can be identified and evaluated to determine probable delays, and potential mitigating action.
• If risk is realized, the risk management plan will provide a pre-planned course of action.

Un-Predictable Delays - Document Project Delays Risk & Have Contingency & Management Reserves Ready:

• Unexpected delays are those that were generally not foreseeable, and plan them in risk management plan to reserve Contingency & Management Reserves

Corrective: Technique to Fix Delays & Bring Back on Schedule:

Plan Additional Work / Resources

• Once you realize that there is a delay, organize a team meeting.
• Inform everyone working on the project about the delay, including details such as factors contributing to the holdup and how far it has set the project back.
• Ask for input and ideas on how to get back on schedule, and plan a course of action moving forward.
• Decide whether you need additional work from team members or supplementary resources are required.
• Also asking for volunteers who are willing to take on extra tasks as needed is advisable, as well.

Cut Any Fat (Lean Thinking)

• Determine whether there are any assignments that can be trimmed down or done away with completely.
• Scaling back on unnecessary tasks will not only get you closer to your schedule but also ensure that your team has the time needed to produce quality work.

Notify Stakeholders

• Keeping project stakeholders informed and up-to-date when there is a delay is a good practice.
• If there is a holdup, it is better for them to hear it from you than to get wind of it through the rumor mill.
• Your transparency will re-assure them that you are well aware of the causes of any project delays and that you have everything under control.
• At times, updating stakeholders on end date changes allows them to plan accordingly, as well.

Notify External Dev/Testing Teams

• Get in touch with external teams is also important.
• On the other hand, you might need to ask a contractor if they can have their part of the project completed even earlier in order to put other tasks on hold.
• You may need to let some of them know that you will not be needing their services until a later date (and save project cost), if their role in the project has been moved back due to the delays.
• Either way, keeping the lines of communication open can eliminate potential problems that would only cause more delays.

Finally, step away from the project briefly. Give yourself time to catch a breath and process all of the readjustments.
Then you can head back to the tasks at hand with renewed perspective and focus on what is yet to be completed.
Doing so ensures that you are able to give the project your full attention without risking the quality on which you have built your reputation.

Hope this helps!!!

Liked reference: https://www.ittoolkit.com/how-to-it/projects/manage-project-delays.html

Arun Manglick
(AWS-ASA, SAFe Agilist, PMP®, PMI-ACP®, PRINCE2® Practitioner, CSM®, MS-Project, CSSGB, ITIL V3, MCPD, MCTS)

How Project Manager Start/Manage Projects

Project managers need a broad range of skills. Here is the complete DNA/guide to know 
- How to Start a Project, 
- How to Execute Project and 
- How to Monitor and Control Project &
- How to Close the Project

Process Group Wise Details as below: 

1). Project Initiation - Link

• Understand Business Case
• Create Project Charter/ PID
• Formally Outline What/Why/Who, How & When
• Prepare Project Purpose/Objective/Business Case
• Prepare High Level Requirements
• Prepare High Level Estimates
• Prepare Conceptual Level Design
• Prepare High Level Initial Risk/Assumptions/Constraints/Dependencies
• Prepare Inclusion/Exclusion from Scope
• Project Manager Selection
• Identify Stakeholders
• Specifically define what stakeholders need and expect from the project
• Formally present the Project Charter Details and Gain Acceptance with Business for further Planning & Execution.

2). Project Planning

• Collect Project Requirements/Scope:
• Detailed Requirement Gathering – Functional Specifications & Use Cases
• Define Scope & Scope Breakdown(WBS)
• Define Activities & Micro Estimation 
• Estimate Activity Durations
• Estimate Resources – Same 
• Determine Project Cost/Budget – 
• Define Project Cost & Budget – DRCP
• Consider a variety of cost alternatives when developing my original project budget plan.
• Consider & include extra funds in the budget and hope that project run under cost at the end
• Create Project Plan & Project Schedule
• Formally create a Project Plan having all the details - Project Background, Objectives, Scope, Constraints, Assumptions, Dependencies & Impacts, Issues & Risks, Methodologies & Strategy, Controls - Scope/Time/Cost/Quality, Resources, Communications, Schedule of delivery, Team Charter, Performance Measurement Metrics, Benefits Realization.
• Prepare a specific timeline and sequence of activities, and use this schedule to manage the overall project to ensure its timely completion
• Plan Quality
• Identifying Quality Requirements and Quality Standards for the project and product, and documenting how the project will demonstrate compliance – i.e. What work will be done to meet the standards. 
• Identify Risk
• Identify as many potential project risks, their Probability/Impact, Response Strategies, Mitigation Plan, Contingency Plan/Reserve, Management Reserve, Residual Risk, Secondary Risk etc.
• Plan Approval
• Formally discuss Project Plan, Estimates, Schedules, Delivery Timelines, Project Status Reports Formats, Project Plan with Business before moving to Execution Phase.

3). Project Execution

• Execute Project According to Project Plan & Project Schedule
• Communicate what needs to be done by what deadline, and expect the people to whom I assign the work to be responsible for breaking down the work packages into smaller and more manageable pieces
• Outline clear expectations for the project team, and I manage their individual and collective performance as part of the overall project evaluation process
• Give people a deadline to complete their project work, and then I expect them to coordinate with others if and when they need to.
• Conduct Daily Team Meetings to tract work and Impediments
• Plan Interim Demos and Release and Gain Early Acceptance with Business
• Handle Change Request, if any
• Take Preventive/Corrective Measures to Avoid/Fix Project Delays - Link
• Routinely monitor and reevaluate significant risks as the project continues
• Keep all project stakeholders informed and up-to-date with regular meetings and distribution of all performance reports, status changes, and other project documents.

4). Project Monitoring

• Monitor & Control Project Delays & Schedule
• Monitor & Control Project Scope, Cost & Budget
• Monitor & Control Project Risks
• Monitor & Control Third Party Vendors, if any

4). Project Closure

• Gain formal acceptance of the project/product
• Create Lessons Learned
• Handover, if any

Knowledge Area Wise Details as below: 

Project Integration 

• Develop a solid understanding of the project's goals.
• Start by producing a Business Requirements Analysis, and then develop a comprehensive Project Initiation Document, which covers the basic project needs and outcomes, so that everyone can understand the project's goals. 
• To prepare this critical, high-level document, you need to understand the phases and processes of project management. This overview will help you become better prepared for what's ahead.

Scope Management 

• Projects have a nasty habit of expanding as they go along, making it impossible to hit deadlines. To control this “scope creep,” it's essential to define the scope at the very start of your project based on the Business Requirements Analysis, and then manage it closely against this signed-off definition. 
• For more on how to do this, see our article on scope control.

Time/Schedule Management

• A project's scope can easily grow, and so can the time needed to complete it. 
• For a project to be completed successfully, despite all of the unknowns, it's important to clearly define the sequence of activities, estimate the time needed for each one, and build in sufficient contingency time to allow for the unexpected. 
• With this information, you can develop a Project Schedule and then begin breaking it down into very specific pieces of work using a Work Breakdown Structure. 
• A schedule often isn't enough. To keep track of the various activities, Gantt Charts and Critical Path Analysis are often helpful.

Cost Management 

• To determine what a project will cost, you must be systematic with your estimating, budgeting, and controlling. 
• Also, be aware that many project decisions will have an impact on cost. 

Quality Management 

• To achieve quality, ensure that you actively manage project benefits. By continuously referring to the benefits that the project will provide, you keep client quality at the forefront – and you won't waste precious time and resources trying to achieve an inappropriate level of quality. 
• An effective project manager knows the importance of checking that project outcomes are consistent with needs. The Deming Cycle (Plan-Do-Check-Act) and Business Testing are important tools for this, as they both force you to consider the needs of the end users. 

HR/People Management 

• Right mix of interpersonal and political skills is just as important as the right technical skills. 
• To help your new team start working together effectively as soon as possible, develop a Team Charter and outline performance expectations. 
• Use well-informed task allocation and appropriate team management skills to keep the project team on track and working productively. 
• And be prepared to help people through the Forming, Storming, Norming and Performing stages that so many teams go through.

Communication

• As with most situations, effective project communication means communicating with the right people at the right time and in the right way. 
• To do this, Stakeholder Management is essential. When you analyze your stakeholders, you identify who must be kept informed in full, and who needs less intensive communication. This can save you a lot of time, and helps you maintain good relationships with people involved in the project.
• Project Dashboards are great for presenting project updates in a way that people can quickly understand. For longer projects that require periodic status reports, Milestone Reporting is effective for capturing the essentials of a project's status.

Risk Management 

• Project managers must understand which of the risks to their plans are significant. An Impact/Probability Chart will help with this. 
• From there, develop a plan for monitoring and controlling the major risks involved in your project. 
• Using your Risk Analysis, develop options to reduce risks, prepare Contingency Plans, and decide who is responsible for which parts of risk response.

Project Procurement 

• Unless your project is in-house, external suppliers will generally have a large impact on your costs. Suppliers will also affect whether the project delivers on time and to specification. 
• Take the time to define your needs in a Request for Proposal document, and then use an appropriate Procurement Management approach to select the best supplier. 

Hope this helps.

Arun Manglick

(AWS-ASA, SAFe Agilist, PMP®, PMI-ACP®, PRINCE2® Practitioner, CSM®, MS-Project, CSSGB, ITIL V3, MCPD, MCTS)

What should be in a Project Plan?

How to Write a Successful Project Plan?

 

The Project Plan is one of the most important and useful documents in your toolkit, and should be referred to and updated throughout the project lifecycle.

Its initial purpose is to kick-start the project by convincing the decision makers that the project is viable and will meet their needs and timeframes / budgets / expectations.

If the Project Plan is poorly written or contains insufficient detail, the project may not even get past this first decision gate and may never actually get off the ground.

Don't confuse a Project Plan with a Project Schedule. A schedule is merely a component of a Project Plan, and usually takes the form of a timeline / GANTT chart depicting tasks vs. timeline.

A project schedule is a vital tool and should complement the project plan. Larger Project Plans contain several schedules, normally as appendices, that are referred to throughout the document.

Such schedules would include an overall timeline, a test schedule, an implementation schedule, the critical path analysis, a resource allocation schedule....etc 

What should be in a Project Plan?

The Project Plan serves as a roadmap for the entire project team providing guidance on the priority of activities, the scope of work, the methodologies and governance to be used, who the stakeholders are, the broad strategy to take, how costs and people will be managed, the quality standards in the project, how the project will communicate with stakeholders, how performance and benefits will be measured...etc

The main areas you need to cover in your plan include:

• Overview
• Project Background
• Objectives & Scope
• Constraints & Assumptions
• Dependencies & Impact
• Issues & Risks
• Methodologies & Strategy
• Controls - Scope, Time, Cost, Quality, Resources
• Communications
• Impacted Business Areas 
• Definitions and Acronyms 
• Project Related:
• Project Lifecyle
• Traceability Approach
• Change and Issue Management Approach 
• Schedule of delivery
• Milestones
• Budget
• CAR Approach
• DAR Approach
• Project Team
• Project Organization
• Project Team Structure
• Roles and Responsibilities          
• Staffing & Training               
• Project Control
• Process Deviations    
• Project Data Management         
• Project Metrics 
• Performance Measurement
• Project Monitoring and Control
• Quality Objectives and Metrics 
• Project Communication
• Stakeholder and User Involvement
• Project Governance
• Project Status Reports & Frequency
• Project Environment
• Infrastructure, Critical Computer Resources and Facilities
• Hardware and Software Environment             
• Testing & Training    
• End User Training          
• Deployment Strategy and Approach       
• Training Approach          

As you can see there are many elements to a Project Plan, and some of the larger plans can stretch well over a hundred pages. This makes structuring your document all the more important.

A consistent format with a logical order (as below) and clear headings will allow your readers to quickly navigate through the document and get to the details that are important to them.

Visit the link: http://www.pmmilestone.biz/ to get a Complete Set of 7000 plus Project Management and Business Templates, Plans, Tools and Forms with detailed guides and examples.

And everything a project manager needs to deliver a successful project. And these templates Can Increase the Efficiency of Project Managers to Meet the Project.

Reference: https://www.linkedin.com/groups/37888/37888-6174499681943437315

Thanks & Regards,

Arun Manglick,

Why Estimate In Story Points

This post outlines the key points in favor of estimating user stories in story points. These include:

• Story points help drive cross-functional behavior
• Story point estimates do not decay
• Story points are a pure measure of size
• Estimating in story points is typically faster
• My ideal days are not your ideal days

  

Story points help drive cross-functional behavior

Agile teams include members from all disciplines necessary to build the product, including programmers, testers, product managers, usability designers, analysts, database engineers, and so on.

Estimate in story point presents a single number that represents all of the work for the whole team. Thus Estimating in story points can help teams learn to work cross-functionally.

On the other hand Estimating ideal days,  often involves specialty groups estimating how long "their part" of a story will take and then summing these sub-estimates.

For example, the programmers may conclude that they need three ideal days, the database engineer needs one, and the tester needs two. An estimate of six ideal days is then assigned to the story.

This small difference in how the discussions about a story take place (to provide a single story point) have an ongoing impact on how the story is developed.

Story Point Estimates Do Not Decay Or Has Longer Shelf Life

An estimate expressed in story points has a longer shelf life than an estimate in ideal days.

An estimate in ideal days can change based on the team's experience with the technology, the domain, and themselves, among other factors.

To see why, suppose a programmer is learning a new language and is asked how long it will take to program a small application. His answer may be five days.

Now, jump forward a few months and ask the same programmer how long it will take to develop an application that is of exactly the same size and complexity.

His answer may be one day because he has become more skilled in the language.

We have a problem now because at two different times, even the applications are exactly the same size, yet they have been estimated differently.

We would like to think that measuring velocity over time would correct or account for this problem. It won't. Instead, we'll see a consistent velocity even though more work is being done. Suppose this programmer is the only person

on the team and that he is working in one week iterations. The first time he develops the application, he has estimated it will take five ideal days. Let's suppose he's in an environment where a calendar day equals an ideal day. He then starts this application on the first day of the iteration and finishes it on the fifth. He has a velocity of five for that iteration. Then, a few months later, because he estimates a similarly-sized application as one ideal day, he will complete five of them in an iteration. His velocity is again five, even though he did five times as much as work as before.

For some projects, especially those adopting new technologies or on which the team is new to the domain, this can be a consideration. Note that both story point and ideal day estimates will need to be updated if the size of an effort changes based on the development of a framework, for example. However, only ideal day estimates need to change when the team the team becomes better at something.

Story Points Are a Pure Measure Of Size

Story points are a pure measure of size. Ideal days are not. Ideal days may be used as a measure of size, but with some deficiencies.

As noted in the preceding section, an estimate in ideal days will change as a developer's proficiency changes. This does not happen with story points—the size is what it is and doesn't change. That is a desirable attribute of any measure of size.

Estimating in Story Points Is Typically Faster

Teams that estimate in story points seem to do so more quickly than teams that estimate in ideal days.

In order to estimate many stories it is necessary to have a very high-level design discussion about the story: Would we implement this in  the database? Can we re-use the user interface? How will this impact the middle tier? are all questions that come up at one time or another. My experience is that teams estimating in ideal days have a tendency to take these discussions a little deeper than do teams estimating in story points.

The difference is presumably because when estimating in ideal days it is easier to  think about the individual tasks necessary to develop a story, rather than thinking in terms of the size of the story relative to other stories.

My Ideal Days Are Not Your Ideal Days

Suppose two runners, one fast and one slow, are standing at the start of a trail. Each can see the whole course of the trail and they can agree that it is 1 kilometer.

They can compare it to another trail they've each run and agree that it is about half the length of that other trail. Their discussions of trail size (really distance in this case) are meaningful.

Suppose instead of discussing the length of the trails these two runners discussed the time it took to run the trails. The fast runner might say, "This is a six minute trail," to which the slow runner would respond, "No, it's at least a ten minute trail." Each would be right, of course, but they would have no way of settling their differences other than agreeing to always discuss trails in terms of how long one of them (or some other runner) would take to run the trail.

This same problem exists with ideal days. You may think you can completely  develop a particular user story in three ideal days. I think I can do it in five days. We're both probably right. How can we come to an agreement? We might choose to put your estimate on it because we think you'll be the one to do the work. But that might be a mistake because by the time we actually do the work you may be too busy and  someone else maybe doing it. And I'll be late because it's estimated at three days for you but will take me five.

What most teams do is ignore the issue. This is acceptable if all developers are of approximately the same skill or if programmers always work in pairs, which helps balance out extreme differences in productivity.

http://www.deltamatrix.com/agile-estimation

Happy Blogging!!!!

Regards,

Arun Manglick

---

本メールおよび添付ファイルは、機密情報を含んでいる可能性があります。そのため、宛先人以外の方による利用は認められておりません。宛先人以外の方による本メールの公表・複写・転用等は厳禁であり、違法となることがあります。万が一、本メールを宛先人以外の方が受信された場合は、お手数ですが、直ちに発信人にお知らせいただくとともに、本メールを削除するようお願いいたします。

The contents of this email and any attachments may include confidential information. Therefore, they may not be disclosed to, used by, or copied in any way by anyone other than the intended recipient and any such disclosure, use or copy can be treated as illegal. In the case this email is sent to you in error, please inform the sender and delete this email.