-
PMP and ITIL: Effects on IT Businesses
October 6, 2008
-
Risk Team Members
October 6, 2008
-
Testing in Project Management - Programmer’s Ego
October 6, 2008
-
Building a Team in Project Management
October 6, 2008
-
Simplify the Job
October 6, 2008
-
Relationship of Project Life Cycle to Phases of the Project Management Life Cycle
October 5, 2008
-
Project Management Approach to Implementing ITIL
October 5, 2008
-
Project Management Controlling Phase
October 5, 2008
-
Differences between ITIL and PMP
October 5, 2008
-
Skills and Attributes of the Project Manager
October 4, 2008
To multi-task, or not to multi-task?
August 10, 2007 | Author: admin | Filed under: Scheduling, Risk Identification
To multi-task, or not to multi-task?
By Adrian Abramovici
Multi-tasking is the biggest killer of schedule
In the simple example shown in the above picture, an employee gets 10 days each to complete a task for each of projects A, B and C. The first example has the schedule allocated by each project for this task also at 10 days, with the projects scheduling their tasks such that the employee can perform the tasks consecutively. Being a good employee, in example 1 she performs the tasks in 10 days each, and on schedule, so her CPI is 1 and the SPI is 1. Great!
In the second example, the projects schedule the tasks such that the single resource is overloaded and insist she must start work on all projects more or less simultaneously, and of course they all want their jobs done NOW. Again, our employee performs her task as given, doing her best to please and support everyone more or less equally, and by the way performs each project task in 10 days each. CPI = 1! Her reward – being called to the carpet by two of the three Project managers for having missed her schedule!
Was it the employee’s fault? No! Multi-tasking is the biggest killer of schedule. And of course the examples above ignore setup/wind-down time, not negligible even in engineering tasks, and multi-tasking related “unplanned” interruptions (e.g. questions, meetings, status reporting).
Given the constrained resources of most businesses today, the constant drive to do more with less, dedicating key individuals to a project full time until it is complete is easier said than done. In most organizations labour is expensive and often scarce, with projects competing for resources, especially the more skilled, expert resources. Consequently, managers will split critical individuals between two or more projects to make fullest use of any gaps in their workload.
As for as resource utilization is concerned, it is logical to assume that a person will have gaps in any task – waiting for inputs, for a peer-review and such comes to mind. So having another project handy to fill in the gaps makes sense, if we do not overdo it. There is survey evidence showing that to maximize productivity, key engineering resources should handle two projects, but if they have more, productivity drops again.
However, if the schedule is the critical driver, then dedicated staffing is a must. Just as the simple intuitive diagram at the top hinted, the survey showed that splitting an engineer’s attention between two (or more) projects does not make both those projects get there in half the time, or at least not if they both required a full time person to get it done..
I am happy that a controlled survey confirmed after surveying close to 10,000 engineers the gut-feel conclusion I had, but the simple numbers game is not all there is to it. I am opposed to multitasking in all but the direst situations for other reasons as well – accountability, team-building, communication, and so on. You can’t build a team of part-timers, communication requires presence, and of course, a dedicated person is much more accountable. Not to be nasty, but I did encounter one or two people playing one project manager against another and getting away with not doing much for either in my time. When the resource is dedicated to one single project, that “degree of freedom” is gone.
All in all experience, gut feel and survey data confirm it: if your project is schedule critical, avoid multi-tasking manpower as much as possible. Multi-tasking is good for the resource managers, not for the project managers.
Adrian Abramovici is, after more than 25 years of aerospace project management, an executive in the rail transportation industry based in Toronto, Canada. He is writing about his experiences and views on Project Management, Risk Management and the day-to-day frustrations and successes of leadership at http://themasochisticpm.spaces.live.com
Related Articles
No comments yet.
feel free to leave a comment
Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!
XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>
All fields marked with " * " are required.
- Agile Project Management
- Certification
- Change Management
- Communications Management
- Computer Based Information Systems
- Concepts
- Corporate Transformation
- Cost Management
- Critical Chain Project Management
- Delegation
- History
- HR Management
- Implementing Project Management
- Integration Management
- Lessons Learned
- Management
- Miscellaneous
- People Issues
- PMBOK
- PRINCE2
- Procurement Management
- Program Management
- Project Management Advantages
- Project Management Best Practices
- Project Management Charts
- Project Management Definitions
- Project Management Ethics
- Project Management for Beginners
- Project Management Musings
- Project Management Office
- Project Management Proposals
- Project Management Templates
- Project Portfolio Management
- Project Workforce Management
- Quality Management
- Requirements Management
- Risk Management
- Scheduling
- Scope Management
- SCRUM
- Soft Management
- Time Management
- Training
- Uncategorized