The Right Way to Fast-track or Crash Your Project

/in /by

Fast-tracking means scheduling tasks in parallel when possible. Crashing is adding people or spending money to complete work earlier. Don’t be overly ambitious with these techniques. Here are some dos and don’ts for fast-tracking and crashing:

Do look for opportunities to fast-track or crash. These strategies can shorten the schedule, but also add risk — so make sure they’re worth it.  Fast-tracking increases the risk of rework because products developed in parallel might not integrate. Crashing increases cost, because you must obtain and coordinate additional resources. 

Do add review tasks after fast-tracking. Adding review time lenthens your schedule, but not as much as you save by fast-tracking.  Reviews mitigate the integration risk of fast-tracking. Team members who work on parallel tasks should conduct joint reviews to ensure products are compatible. 

Do use skilled resources to crash your tasks. Adding skilled team members can improve the quality of the product and save time.

Don’t add marginal skills to tasks you’re crashing. Lack of skill creates more overhead – ensure you have capable people. Also, limit the number of people on crashed tasks. Too many people get in each other’s way, wasting time and money.

Don’t compromise project integrity by fast-tracking testing. Testing tasks should be exempt from fast-tracking. Testing evaluates the appropriateness of your products. You can’t conduct high-integrity tests while product development is still in progress. If you do that, you’ll need additional regression testing, which negates the fast-tracking time savings.

Don’t apply both fast-tracking and crashing to the same tasks. This increases risk dramatically and is rarely successful. I call this “fast-crashing,” because, like a car accident, you can’t help but look, though the results aren’t pretty.  

For more on these techniques, watch my LinkedIn scheduling course

 

What you can and can’t change in Agile

/in /by

Agile methodologies accommodate change easily, which is why they’re called -er- agile! However, some things don’t change. Here’s an overview of what you can and can’t change with agile:

Priority.  Each sprint includes a review and re-prioritization of the functional backlog, so you can change priority before each sprint.  Prioritization of items commonly occurs as functions are produced and stakeholders learn from using those functions. New business challenges and the benefit of new functions can come to light and be addressed. Priority changes must comply with technical practicalities and logical business sequences. For example, you can’t build a balance sheet unless you can process both revenue and expenses!

Schedule. When you review the functional backlog, you can adjust the schedule by moving the functions the business needs or wants into upcoming sprints. However, rescheduling requires accurate effort estimating.Developers learn more about the functions they produce, which improves their ability to estimate effort. As a result, you can more easily manage the schedule as the project progresses.

Scope. New scope ideas often surface after a few functions are produced. Scope changes are not only accommodated, but expected, with agile approaches. However, this often involves trade-offs. Budget and time negotiations or dropping existing scope items to accommodate new and important functions are likely to occur.

Deadlines. Agile projects usually involve allocating personnel for a pre-determined amount of time. Scope becomes the variable. As scope changes or reprioritizations are discussed, you can adjust the sprints to change deadlines for specific functions. The overall project deadline can even be changed– assuming the whole team is still available.

Don’t count on changing cadence or personnel! Setting the agile team anda sprint schedule – and sticking to it – are major success factors with agile. A major benefit of agile is what is learned along the way. Changing personnel disrupts that learning and diminishes agile benefits. Changing sprint structures can also be disruptive. Schedules are built around the vital, focused sprint meetings and activities. Changing the schedule can throw the team off their rhythm and disrupt the estimates and sprint plans that have been created.

For more on agile, check out the Become an Agile Project Manager learning path 

The Benefits of Dedicated Resources

/in /by

Dedicated project team members might appear expensive, but they provide significant benefits, which might reduce your project costs:

Focused responsibilities. Dedicated people aren’t distracted by day-to-day operational issues. They can fully examine the project deliverables and understand how the project is proceeding so they can deliver what’s best for the project. You get better outcomes and reduce rework.

The right skills for the job. Operational knowledge is important, but it doesn’t necessarily mean the person has the best skillset to create project deliverables. Recruiting people with the most appropriate skills and assigning them to project tasks can optimize your project delivery. Contractors can join the project as dedicated resources for only the time needed to accomplish their tasks, which can reduce project overhead costs.

Greater efficiency. Dedicated, skilled team members typically take fewer hours to produce their deliverables because they don’t have to multi-task. Multi-tasking wastes time while not making progress — like catching up when you reopen a novel after putting it down. Operational personnel who also produce project deliverables are multi-tasking: they need to re-acclimatize themselves each time they switch between operational and project work. This wastes time and increases costs.

Continued access to operational knowledge. Assigning dedicated team members to your project doesn’t necessarily mean losing operational knowledge. Your dedicated team members can interview or shadow operational personnel to obtain first-hand knowledge of business operations and then apply that knowledge to your project deliverables.

Quicker delivery. The efficiencies of dedicated resources can mean a shorter project. Your business value is realized more quickly, and you can move on to your next project – and deliver more business value sooner!

To learn more, watch Chris Croft’s course Managing Resources Across Project Teams.

 

A Project Manager’s Responsible Optimism

/in /by

The pessimism of Eeyore, the gloomy donkey from Winnie-the-Pooh, would make him an uninspiring project manager. But unchecked optimism isn’t good either—you come off as unrealistic. Here are some tips for achieving the balance of constructive optimism:

  • Complement optimism with risk management. Balance your optimism with constructive risk discussions. Openly surface issues and the response actions you are taking. Create a risk management culture within your project. You can enhance stakeholder management with well placed optimism based on your experience and abilities. Taken too far, you may create concerns that you’ll overlook roadblocks.
  • Support optimism with history. Strengthen the validity of your optimism by referencing past successes. Successes from your current organization are the most powerful. When your history comes from elsewhere, discuss the characteristics your current organization has in common with past environments. This bases your optimism in fact, versus only a cheerful attitude.
  • Accept any pessimism you may encounter. But address that pessimism with open dialog to determine how to manage the situation. While pessimism can be draining, pessimistic viewpoints can raise valid risks. Don’t discard them without first evaluating their validity.
  • Be yourself. You became a project manager because of your skills and abilities. You shouldn’t change what you do now! Be mindful of how your optimism or pessimism affects others. Using the tips suggested here, tweak your levels if necessary. However, don’t fake optimism. People see through this eventually, and it’ll do more harm than good.

For more on project management, follow me on LinkednIn (https://www.linkedin.com/in/bonniebiafore/) and check out the LinkedIn Learning Become a Project Manager learning path

Prioritize your PM Work

/in /by

There are hundreds of things you can do as a project manager to deliver a project. How do you prioritize what’s on your project management to-do list? Here are tips from the pros:

Let the environment guide you. Monitor your project environment and respond to concerns that arise. Things change day to day in a project. Teams can get stressed. Key staff can argue. Stakeholders hear rumors and get fearful. Unexpected issues arise. Ensure you address these concerns, and you’ll create a positive environment for project delivery.

Accommodate your senior stakeholders. Design your to-do list around what your stakeholders need to trust in your project management. Understand their desires. Are they detail oriented? Do they want frequent status updates, or alerts only if there’s a problem? The last thing you want are worried senior leaders, so accommodate their needs – but don’t hide bad news from them!

Focus on risk. Keep risk monitoring in the forefront. Talk about risk often with your team. Watch for risk triggers and be proactive with your response strategies. Supporting a risk management mindset is powerful – make it a significant part of your to-do list.

Complement your project team. Every project team has strengths and weaknesses. Use your experience to make up for team shortcomings.  When appropriate, offer your help and teach your team members. Ensure you aren’t taking over their responsibilities —  you already have enough to do as the PM!

Support your team. Your team is crucial to project success. Take care of them. Pay attention and support their needs. Thank them when they do well and guide them when they go astray. It’s easy to forget this in hectic project environments, so ensure supporting your team is a to-do list priority.

For more info, watch my course Project Management Foundations.

Managing the critical path isn’t enough

/in /by

You manage your project schedule by focusing on the critical path. But don’t stop there! Project time management requires examination of other items. Here are things to check to proactively manage your schedule:

Examine “near critical paths.”A path with a small amount of slack means you have a near critical path. These tasks with very little slack should be monitored with the same diligence as your critical path, because almost any task delay could shift your critical path. 

Watch resource work time. Monitor variances between forecasted and actual work hours on your project. Consistent under-allocation of actual work time on project tasks could lead to schedule slippage. Ensure you understand why resources aren’t working as much as planned. Work with management if a reallocation of project tasks is necessary to keep things on track.  

Look for convergence tasks. Successor tasks with multiple paths leading into them are prone to delay, because many predecessor tasks must complete on time to keep the convergence task on schedule. Monitor progress leading up to convergence tasks and proactively respond if delays seem likely. Note: convergence tasks are candidates for contingency because of the likelihood of delays.

Note upcoming risks. Understand your risk triggers. Explore additional resourcing, fast-tracking or crashing alternatives if risks appear poised to come to fruition. Examine the possibilities for other risks due to delays to your schedule, such as losing staff to other initiatives or contractor agreements expiring.

To learn more, check out my Project Management Foundations course.

 

Less Wrong Estimating

/in /by

It’s irresponsible to promote early estimates as being accurate. Early on, there are too many unknowns. A responsible approach focuses on communicating our estimates as gradually more accurate. Here’s what you can do to produce responsible estimates.  

  • Label your estimates. An estimate without a label implies the value is accurate. Label your estimates to indicate their accuracy, such as rough order of magnitude, budgetary, or definitive. Define the accuracy range for each label, such as -20% to +50%. Then, indicate when a more accurate estimate can be produced.
  • Re-estimate at key points in the project. Events like finalizing a contract provide significant information to improve your estimates. Produce refined estimates after each of these events. Develop and communicate a schedule for re-estimating, tied to the events, to demonstrate a clear rationale for how you intend to incrementally improve your estimates. 
  • Keep refining estimates during project execution. Don’t stop estimating after planning is complete. As major deliverables are produced and costs become known, continue to refine your estimates. This further demonstrates that estimation accuracy evolves, and reflects your concern for the money and time you spend.

Project management entails managing expectations. You can set expectations about estimating by creating an estimating schedule and estimating to that schedule as your project progresses. That’s a responsible and rational way to manage estimating.

To learn more about estimating, check out the estimating movie in my Project Management Foundations course.

#projectmanagement #projectpointers

Choosing the correct task dependency is easier than you think

/in /by

Each task has a start and finish, so there are four types of task dependencies: finish-to-start, finish-to-finish, start-to-start, and start-to-finish.

In most projects, most (90% or more) dependencies are finish-to-start (FS). When one task finishes, it triggers the start of the next, like when cooking dinner is finished, eating dinner begins (assuming you don’t sneak bites while you’re cooking). That means you’ll check if FS is the right one first.

For the rest of your task dependencies, finish-to-finish (FF) is probably the one you need. This means, the finish of one task controls when the other task finishes. Hauling trash away from a job site doesn’t finish until construction is complete.

Start-to-start (SS) and start-to-finish (SF) don’t show up often.  Start-to-start can cause problems if the predecessor task runs late. And start-to-finish simply doesn’t arise very often.

The bottom line: You almost always use two of the four dependency types. To learn more about dependencies, check out my Project Management Foundations: Schedules course or see how to create dependencies in my Learning Microsoft Project course.  

#microsoftproject #projectpointeres #projectmanagement

Can you have too much authority as a project manager?

/in /by

Bob McGannon and I talk about whether a project manager can have too much authority. We also talk about what to do to make sure everyone understands the authority the project manager does have.

https://youtu.be/oz7ydHpboVc

A tip for introverted project managers: Your team probably likes you that way.

/in /by

Many of your team members are introverts. Engineers, developers, technical folk of all ilks tend to introversion. They usually want clear, rational reasons why the project is important and how they fit into the project picture. They almost always dislike sales pitches and hype.

As an introverted project manager, you are probably most comfortable organizing the project environment and making sure the work gets done. You also understand the importance of the project, the makeup of the players, and lots more. You are the perfect person to help your team members grasp the info they need, because you can talk in their language.

What’s more, you don’t have to be a cheerleader to lead a team. Introverts can inspire and motivate people just fine. Think leading by example. Or guiding and growing your team members behind the scenes. (As an introvert, you’re likely to manage people with a lighter touch than extroverts use.) And using thoughtful, yet powerful persuasion to convince people at all levels to do what’s needed.

To learn more about leading, check out the courses in the LinkedIn Learning Become a Leader learning path.