Critical Action Planning is my attempt to combine key elements of Critical Chain planning with an Agile/Kanban philosophical approach, specifically for companies developing physical/hardware products. Like the Critical Chain, Critical Action project management is based on a detailed best-case task list for the complete project. Like Agile/Kanban, we don’t define task dependencies or projected task start or end dates. Also like Agile/Kanban, we estimate the amount of best-case work-units required to complete each task (e.g. in person days). Eliminating dependency and date planning dramatically simplifies the planning process, and makes the project plan parseable. Like Critical Chain, we add a buffer to the best-case plan, by including tasks to represent potential re-work or project iterations. We estimate work-units for these tasks too.
That’s the Project Plan – a comprehensive list of tasks with estimated work-units for each. I keep the list in a spreadsheet, which I share with the project team. Adding, modifying or subtracting tasks is lightweight, making it easy to update the project as we go along, but we’ll discuss that more later. Today I just want to concentrate on the initial Project Plan, and introduce some terminology.
I prefer to organize the Critical Action Project Plan into groups of tasks, to make it easier for the team to understand. First, I make a separate task list for each phase in our stage-gate process. We have five phases, so I make five lists. This makes it clear which tasks belong to which phase. Second, within each phase’s list, I insert headers into my list to logically group tasks. For example, the task header “Verify guide wire motion” might include tasks such as write the protocol, build the test samples, run the tests in the protocol, analyze the data, and write the report. Adding headers tasks is similar to adding headers in Gantt charts. BTW, I insist that each task starts with an action verb, and that each task clearly defines the deliverable so that all on the team can understand. If the tasks are unambiguous, the resulting plan is clear and action-oriented.
I put a lot of effort into defining the Project Tasks and their Work-units in the current phase because I’m going to use this Project Plan to manage the project. I spend less time on future phases. I make sure that future phases are reasonable, but I know I will need to adjust them later based on the current phase results. I’m really just trying to avoid major adjustments later. I work with my project team, often with one or two team members at a time, to think through the Project Tasks and Work-unit estimates. We work the plan until it’s pretty good. It doesn’t have to be 100% perfect.
We run our projects with cross-functional NPD teams, so we include the tasks for all functions in the plan, not just engineering and manufacturing tasks. If the tasks are important for the product’s success, they should be in the plan (e.g. interview customers to identify user needs, develop physician training materials, assemble the technical file, file invention disclosures, train the sales force).
Also, don’t forget to put tasks in the plan to update the Project Plan itself. Project Plans need ongoing love and care, like risk analyses and requirements management. In my company, we have a major update and review of the Project Plan before we move from one project phase to the next.
You’ll make your QA team proud if you use the planning process to think about timing and content of design reviews. Incorporate design reviews into the Project Plan now, so that you can account for the capacity required, and you don’t accidentally skip an important review in the heat of the project later.
By summing the estimated work-units for all the tasks in a project, we calculate the total work-units required to complete the project. We call this the Project Scope. More work-units means a bigger Project Scope. Pretty straightforward. If we separated out the task lists for each phase in our stage-gate, we can calculate Phase Scopes.
We can also calculate Weekly Project Capacity. We simply add up the realistic amount of work-days available from the people that will work on the project each week. I assume 3.5 to 4 work-days available per person per week, because I know people need to attend meetings, attend training, work on non-NPD tasks, etc. If someone on my team is managing an outside resource, I make sure I include adequate tasks in the plan for the effort to manage the outside resource, so I’m comparing apples to apples.
Now we can calculate Project Duration, by dividing Project Scope by Weekly Project Capacity. This tells us the number of weeks our project will take, given the current scope and capacity. Notice that we haven’t assigned individuals to specific tasks and done standard resource leveling. I assume that people have breadth, so that more than one person could tackle any given task. We’ll figure out who does what later. I can also calculate Phase Duration, to estimate how long the current phase will take. In my experience, when you miss the phase deadline, you never recover to hit the project deadline. So you really need to understand your Phase Duration. Sometimes, the Phase Duration or Project Duration is longer than desired. I’ll make some suggestions about handling that in a future post.
That’s it for today.
Critical Action Planning: A hybrid of Critical Chain and Agile/Kanban Project Management for Medtech and other hardware companies.
Project Plan: A comprehensive, detailed list of all tasks needed to complete the project (including some assumed tasks for rework and iteration) with work-unit estimates for each.
Project Task: unambiguous definition of a piece of work to be done, starting with an action verb and clearly defining the deliverable.
Work-units: best-case estimate of the total amount of project team effort (e.g. in person-days) needed to complete a task.
Project Scope: the sum of work-units required to complete all tasks in the project plan.
Phase Scope: the sum of work-units required to complete all tasks in a phase of the stage-gate process.
Weekly Project Capacity: the realistic work-units available from project resources (can be team members or outside resources) for one week.
Project Duration: Project scope divided by project capacity.