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.