Task Driven MS Project 2010 Approach
Despite the title of this article – Task Driven, let’s be clear that no matter what project you are involved in, all projects have the following attributes:
- A project manager
- Senior management (this may be the customer, user, business management – or all three)
- An objective, goal, or desired outcome
- An end deliverable or product
- Individual tasks or activities and their relationships
- Resources (people, equipment, tools, facilities, materials,)
- A budget (even if money is not involved, then the ‘budget’ is the provision of the above resources)
But by far the most common attributes of a general project is formed by the so called iron triangle of cost, time, and quality – usually wrapped up within the project scope:
Since scope is defined as what is included within the project and equally as important, what is not, and that the budget is normally set by management, then most project managers would probably agree that most of their focus is on ensuring that tasks and activities start and finish all time and the key dates are met.
The Task Driven with MS Project 2010 Approach
The characteristics of a typical task can be described as having a duration (an elapsed time frame), having start and finish dates, they are carried out by work effort (typically measured in hours), they have at least one resource type assigned to them, and where appropriate each task has a cost associated to it.
Task Driven Planning
It will come as no surprise that Microsoft project 2010 has the facilities to enter all of the above if necessary.
Each task within a project has some form of dependency. The very first task must start on the start date of the project (as soon as possible). The next task may start at the same time, after given duration within the first task, or it must start after the first task has finished. These are simple examples of what is meant by dependencies.
However, there is another form of dependency; the resources required to carry out the work of the task. How long the task takes will depend on the nature of the task itself of course, but also on the number and type of resources are applied to it.
There is just to consider the human resources for now. Each individual will have a set of skills, knowledge and experience. Therefore the work within a task will depend on the skill-set of the individual, as well as the number of individuals carrying out the work.
This is fairly obvious I know, but since this article topic is about Task driven project management, I want you to see that to merely brainstorming the tasks to be carried out, determining their dependencies, and assigning resource to each is not as simple as it sounds.
Some tasks have a logical dependencies, for example you can’t eat the meal until it has been cooked. For other tasks, it may be merely a matter of preference whether one starts before another, or whether they both start at the same time.
But when it comes to resources, whether human or non human, care must be taken to ensure that there are enough resources available to carry out the tasks when they are scheduled to occur.
Let’s invent a resource called Harry, typically Harry may be available 8 hours a day, but if he is being asked to carry out two tasks at once, then he is only available for 50% of his time on each. When you first assigning resources to tasks, it is quite normal to discover that although work effort estimates are accurate, the tasks cannot be carried out on time because of problems such as Harry, above.
In project management jargon we would say that Harry is ‘over-allocated’, and we would need to carry out ‘resource levelling ‘to resolve the problem. Put simply and there are two obvious choices; move the timeframe of both tasks so that Harry is 100% available for each, or to replace Harry with a different but available resource or one of the tasks.
This again brings us back to the title of this article, in that the project manager is primarily concerned with the task management and the creation of a realistic and achievable schedule delivery plan within the constraints of the available resources.
There is another factor that should be taken into consideration and that is of external constraints. These may typically be a date constraint by an external supplier, a key product be made available from another project, or a piece of legislation coming into play. In short, just about anything!
The cost of each and every task including any overheads will give the total cost of the project. In a perfect world this will be the same as the budget allocated by management, but when it is not, then the project manager will need to do revisit to the plan and possibly renegotiate the iron triangle. For example, reduce the scope so that less products and hence tasks are required.
It is important that the project manager involves senior management and customers in such negotiations. Prioritising the iron triangle will help the project manager come up with replanning options that will satisfy management and the customer.
For those new to the use of Microsoft project 2010, the good news is that not only can you tool be used to enter tasks and resources, and in that way provide a model of what needs to be done, but it also provides a host of functions and techniques to resolve all of the above problems – or at least minimize them.
It is very easy for the project manager to feel like a victim here. On the one hand being handed a project that must be delivered within given constraints, but also, as a project manager (apparently gifted with the ability to achieve the impossible!), to somehow ‘force fit’ what needs to be done within such constraints.
But it is not all gloom and doom. The professional project manager, partly with the aid of Microsoft project 2010, has the ability to develop realistic and achievable plans even within the constraints. The important thing here however, is to develop a series of options within the constraints and present them to management so that they can make an informed choice.
It is simply not acceptable, nor desirable, for the project manager just to say yes as it will store up even bigger problems later.
Speaking personally, I would much rather a project manager present me with a set of compelling reasons why my project cannot be done within the constraints (it may be based on the availability of resources alone), and then go on to suggest trade offs that may be negotiated.
In summary, despite the myriad of plates spinning activities that the project manager needs to involve themselves with, it is usually the task focus that wins through.
