| This article was first published on LinkedIn on 19th September 2016 |  |
When Microsoft released Project 2010 one of the new features of the scheduling tool was the ability to include Inactive Tasks.
You may well be underwhelmed or even unaware of the possibilities of Inactive tasks. In this article I explore some of the ways this feature has been used by the people I have worked with when deploying Project Server or running training sessions on Microsoft Project. The examples I provide here are by no means the definitive guide, there are likely to be many ingenious uses for them devised by users as they become more familiar with this feature in Microsoft Project. The official line from Microsoft when announcing this feature was that it allows for simplified planning and what-if analysis, suitably vague there from Microsoft.
Here are several scenarios where Inactive tasks could be of significant benefit when crafting a project schedule.
Scope Change:
The one thing you can be assured of in a project is that things will change and that then things will change again. How many times have you had to remove and then reinstate tasks due to changes being made and then unmade? With inactive tasks you can simply mark a task as being inactive should it be removed from the scope of your project. A record of it is retained in the schedule but it has no bearing on time, work or cost in the project plan. If the task is reinstated it is simply marked as being active once more.
This approach avoids the need for differing versions of the same project plan having to be maintained by the Project Manager. Another useful aspect of this feature is that you can record just how many tasks are recorded as being inactive over the lifecycle of a project which can be a powerful illustration of the disruptive effects of incessant change and also the sources of such change!
Risk Management:
Projects and Risks go hand in hand, invariably a Project is initiated to pursue an opportunity - where there are opportunities there are bound to be risks.
Project Server provides a useful mechanism for tracking risks in the Project Site, an associated SharePoint workspace that is provisioned when a project is first published. Project Sites incorporate a reasonably robust approach to risk tracking. In Risk Analysis we identify potential risks and plan for them accordingly. Our risk list in SharePoint can identify the impact of risk, our mitigation strategy and our contingency plans.
Inactive tasks can be built into a project plan to model mitigation actions that may be required should a risk manifest itself. In risk management the watch words are “this shouldn’t happen, but it if does...” thus inactive tasks can be employed to both allow for mitigation and perhaps more importantly remind people of the potential for risk and the proposed actions that have been agreed to mitigate the risk. Should a risk occur allowing for it in the plan is as simple as activating the relevant inactive task.
Branching Logic:
Have you ever been asked to model different scenarios for the same problem? With inactive tasks you can illustrate the impact of different scenarios in a single project plan.
You might have a phase or stage of a project that could be run in-house or outsourced. In-house will likely take longer due to resource availability whereas outsourcing whilst quicker comes at a price. You can create a plan where two activities have the same predecessor and same successor, this could include an entire section of the plan represented by Summary Tasks (making a Summary Task inactive makes all its subtasks inactive simultaneously). Taking the in-house route the impact on the projects overall time and budget would be different to taking the outsourced option. This gives you the opportunity to consider your options in a reasonably informed fashion.
Change Management:
Working in a robustly governed environment you may well employ rigorous change management processes. I recently worked on a program where key Milestones were subject to Change Control. The Change Control process allowed for changes to key Milestones, the addition and removal of key Milestones from projects in the program. Whilst our change log contained a record of Milestones that had been approved for removal it was agreed that deleting such Milestones from the project plans was an unsatisfactory way of managing this change. By marking such removed Milestones as inactive we retained them in the plans as a matter of record and were able to provide some powerful reporting on these changes direct from the data contained in Project Server rather than having to reference the Change Log itself.
No doubt seasoned users of Microsoft Project will come up with even more imaginative uses of this new feature of Microsoft Project, if you can think of any be sure to let me know. I will of course let you know should I come up with any more ideas myself.
Dominic Moss trades as Projectability "helping your people achieve more"- providing customers with expert guidance and training on the use of Microsoft Project, Project Server and the principles of effective Project Management.
You may well be underwhelmed or even unaware of the possibilities of Inactive tasks. In this article I explore some of the ways this feature has been used by the people I have worked with when deploying Project Server or running training sessions on Microsoft Project. The examples I provide here are by no means the definitive guide, there are likely to be many ingenious uses for them devised by users as they become more familiar with this feature in Microsoft Project. The official line from Microsoft when announcing this feature was that it allows for simplified planning and what-if analysis, suitably vague there from Microsoft.
Here are several scenarios where Inactive tasks could be of significant benefit when crafting a project schedule.
Scope Change:
The one thing you can be assured of in a project is that things will change and that then things will change again. How many times have you had to remove and then reinstate tasks due to changes being made and then unmade? With inactive tasks you can simply mark a task as being inactive should it be removed from the scope of your project. A record of it is retained in the schedule but it has no bearing on time, work or cost in the project plan. If the task is reinstated it is simply marked as being active once more.
This approach avoids the need for differing versions of the same project plan having to be maintained by the Project Manager. Another useful aspect of this feature is that you can record just how many tasks are recorded as being inactive over the lifecycle of a project which can be a powerful illustration of the disruptive effects of incessant change and also the sources of such change!
Risk Management:
Projects and Risks go hand in hand, invariably a Project is initiated to pursue an opportunity - where there are opportunities there are bound to be risks.
Project Server provides a useful mechanism for tracking risks in the Project Site, an associated SharePoint workspace that is provisioned when a project is first published. Project Sites incorporate a reasonably robust approach to risk tracking. In Risk Analysis we identify potential risks and plan for them accordingly. Our risk list in SharePoint can identify the impact of risk, our mitigation strategy and our contingency plans.
Inactive tasks can be built into a project plan to model mitigation actions that may be required should a risk manifest itself. In risk management the watch words are “this shouldn’t happen, but it if does...” thus inactive tasks can be employed to both allow for mitigation and perhaps more importantly remind people of the potential for risk and the proposed actions that have been agreed to mitigate the risk. Should a risk occur allowing for it in the plan is as simple as activating the relevant inactive task.
Branching Logic:
Have you ever been asked to model different scenarios for the same problem? With inactive tasks you can illustrate the impact of different scenarios in a single project plan.
You might have a phase or stage of a project that could be run in-house or outsourced. In-house will likely take longer due to resource availability whereas outsourcing whilst quicker comes at a price. You can create a plan where two activities have the same predecessor and same successor, this could include an entire section of the plan represented by Summary Tasks (making a Summary Task inactive makes all its subtasks inactive simultaneously). Taking the in-house route the impact on the projects overall time and budget would be different to taking the outsourced option. This gives you the opportunity to consider your options in a reasonably informed fashion.
Change Management:
Working in a robustly governed environment you may well employ rigorous change management processes. I recently worked on a program where key Milestones were subject to Change Control. The Change Control process allowed for changes to key Milestones, the addition and removal of key Milestones from projects in the program. Whilst our change log contained a record of Milestones that had been approved for removal it was agreed that deleting such Milestones from the project plans was an unsatisfactory way of managing this change. By marking such removed Milestones as inactive we retained them in the plans as a matter of record and were able to provide some powerful reporting on these changes direct from the data contained in Project Server rather than having to reference the Change Log itself.
No doubt seasoned users of Microsoft Project will come up with even more imaginative uses of this new feature of Microsoft Project, if you can think of any be sure to let me know. I will of course let you know should I come up with any more ideas myself.
Dominic Moss trades as Projectability "helping your people achieve more"- providing customers with expert guidance and training on the use of Microsoft Project, Project Server and the principles of effective Project Management.
RSS Feed