As project managers, we are taught to manage the triple constraint of scope, schedule (or time) and … Read More
No, You Can’t Multitask
Everyone multitasks. You switch from email to a project schedule to a requirements document within minutes, or seconds. You (and everyone else) brings their laptop to a meeting so they can crank out emails. Everyone multitasks, but most people aren’t good at it. Research from the University of Utah (here) shows that less than 3% of the population can multitask with no decline in performance.
To a degree, PMs know that people are bad at multitasking. We would rather have one person 100% of the time on our project instead of five people 20% of the time (assuming equal talents). Then we know what they are working on at all times.
There are certain tasks that don’t suffer if you do them poorly. Many of the tasks that PMs do, such as tracking task completion and issue tracking, don’t require a high level of performance. But you should be worried about your job if all you do is menial tasks that can be easily done while multitasking. Some of the problems that need solving are hard and require full attention. If you aren’t working on the hard problems, then you may not providing value to your organization. You are paid a lot and you should be spending a significant percentage of your time solving hard problems.
It’s clear that people should complete one task at a time. You and your team.
You Train People on How to Treat You
The February issue of Oprah magazine has an article by Dr. Phil called “You Teach People How to Treat You.” I’ve used this saying repeatedly throughout my consulting practice. IT departments frequently get the treatment they deserve.
Here are two example. First, I worked for a company where the entire IT department knew what time the CIO came into work. We knew because we would see a flood of emails from her. Nearly everyone in the company sent her requests and she would prioritize these as the highest tasks to work on (after all, they emailed the CIO). So the entire IT department would work on these requests, regardless of the other projects. Most of these were routine help desk requests about broken keyboards or email issues. I went to her and used one of my favorite project sayings: “When you work off your inbox, you’re working on everyone else’s priorities, not your own.” She argued that IT is a service department and everyone else’s priorities are IT’s priorities. That’s wrong on so many levels but I’ll leave that for another day. The point is that the entire company used the CIO as the IT help desk. And why not? We had trained them to do that – send your problem to the CIO and it will get addressed.
The second example is an insurance company that had a problem finishing projects. The company would not let projects end. The business departments argued that more work was always needed and the project team needed to stay intact to do the extra work. IT hated this as it consumed resources on projects with ever diminishing returns. But IT had no change control process! There was no process to weigh changes against time and resource budgets. IT had trained the business departments to monopolize resources on their own projects for as long as possible.
IT departments train other departments on how they want to be treated. If you have processes, and you follow them, the business departments will follow them too. Especially when they see the increase in productivity that results in efficient processes in project management. More projects done faster with better results can only be consistently achieved with appropriate, proven project management processes.
NASA Project Management Class
This picture is from a combined project management/systems engineering class at NASA’s Kennedy Space Center. If you look closely, I’m seventh from the left. I taught some of the PM modules. The Vehicle Assembly Building (VAB) is to the left, a shuttle is to the right and a launch pad is to the right in the far distance. The last shuttle to fly was in the VAB being decommissioned before retiring into the sunset.
Push vs. Pull Communication for PMs
Email is evil. All of us receive too much. There are many perpetrators of bad email etiquette – the people who email a huge audience with information for just a few people, those who Reply All and cc:, people who try to solve complicated problems through email. Arghh! You’re killing me! Stop it!
Too many project managers succumb to the false allure of email. As PMs we must convey information to a large number of people so email seems like an easy, natural way to do it. But many PMs over-rely on email and they end up spamming people – soon, their emails are ignored altogether.
Push Communication
Email is an example of a push communication. It is pushed from a person to many people. There are three problems with push communications:
- You have to guess the right people to receive the email
- You have to guess the right information that those people need
- Communications are transient
The first two problems are hard – knowing exactly who should receive what information is complicated and takes time. Some PMs don’t bother – they send all information to all people. The result is too many people on the email communication (which is compounded by the numerous Reply Alls ) and too much information in the email. People start to ignore the email because it is either not relevant to them or the relevant information is buried below the fold.
The third problem – transience – becomes an issue on longer projects. Email only reaches the people on the project at the time of the email. Team members that join later miss all of that information.
Pull Communication
A better way is to use pull communication techniques. A classic example of a pull communication is Facebook. People don’t email their personal updates. They simply post them to Facebook. Everyone who was given access can see the information.
How can pull communication be applied to project management? PMs should use intranet sites, blogs or wikis instead of email.
Let’s use an internal blog as an example. A PM would post project information to an internal blog (by internal, I mean only employees can see it – and perhaps a subset of employees if security is needed). A blog automatically solves two of the three email problems: 1) you don’t have to guess the recipients – it is posted for all to see and 2) it is permanent – future team members have access to the exact communications that were originally posted.
How about the third problem – how do you ensure people get to the right information as quickly as possible? With tags. Every blog post is tagged according to the information contained in it (see below “filed under” as an example). Tags for a project would be: project status, budget, risk, procurement, scope changes, and other common project management topics. Then someone who is only interested in the budget (someone from accounting for example) would simply search for posts marked with the budget tag. Or they could set it up where every new post tagged budget is emailed to them. (Microsoft SharePoint can be setup to do all this.)
PMs should switch more communications from push to pull. It enables more efficient communication (which we all need) and fewer emails (which we all want).
It’s All About the Plan(-ning)
I’ve collected a lot of project sayings over the years. Many of them have to do with planning, including the first:
- Fail to plan, plan to fail.
It is the basis of the project management profession. If organizations or teams could/would plan, they wouldn’t need PMs. But they don’t plan. So they need us. Perhaps they live by another saying:
- The nice thing about not planning is that failure comes as a complete surprise, rather than being preceded by a period of worry and depression.
I don’t like surprises. I am risk-averse. I want to plan as much as possible to reduce the risk (and the work) of the project. A few more quotes come to mind:
- Initial planning is the most vital part of a project. The review of most failed projects indicates the disasters were well planned to happen from the start.
- It’s not the plan, it’s the planning. (Graeme Edwards)
- Plans are nothing, planning is everything. (Dwight D. Eisenhower)
- No plan survives contact with the enemy. (Field-Marshal Helmuth von Moltke)
And my personal favorite:
- Everyone has a plan until they get punched in the mouth. (Mike Tyson)
So much risk and work could be avoided if teams simply took the time to plan their work. I know why they don’t. Everyone is busy multi-tasking on many different things at once, perhaps not knowing the priority of each task. But I don’t care. Projects must be planned. Teams must take the time to do this.
And I know most (all?) projects don’t go according to plan. But Eisenhower et. al. are right – it is not the plan that’s important, it’s the planning. Planning enables you to react quickly to problems that come up. Perhaps you’ve already prepared for the problem, perhaps you have appropriate reserves or extra resources to tap. Even if you are not fully prepared for the specific problem that arises, your planning has eliminated some possibilities and again, allows you to react quicker.
I believe Henry Ford knew the reason people don’t plan:
- Thinking is the hardest work there is, which is probably the reason why so few engage in it. (Henry Ford)
Planning requires thinking and too many people, even so-called knowledge-workers, avoid thinking at all costs. They prefer to do stuff. It doesn’t matter what the stuff is, just so they are busy. Email looks like work so a lot of people do it instead of thinking. Going to meetings also looks like work so people spend a lot of time in meetings. (Note: A meeting is only work for the person running it.) Spending (wasting) time in Microsoft Project or PowerPoint looks like work too. And sometimes it is, but a PM should manage the project not the project software.
To reiterate: it is unacceptable to not have a plan. It is a mandatory task (and document). It’s all about the plan(-ning).
Triple Constraint? No, the Triple Trade-off
As project managers, we are taught to manage the triple constraint of scope, schedule (or time) and cost (or resources). It is a way to teach PMs (and others) that there is no free lunch. If you want more scope, then you need to provide more time or more resources. If you want an earlier delivery date (that is, less time) then you need less scope or more resources.
It’s a good concept for beginning project managers. I lived by it for ten years or more. I was working on a project for a Fortune 50 company and my client kept adding scope. I had management reserve to handle a few scope changes but that was quickly exhausted. I spent a weekend developing an analysis that showed that we could no longer meet the deadline with the scope and resources. I was so nervous about the client meeting I brought the president of my consulting company with me to meet with the client. My client cut me off on slide 3 of a 19-slide PowerPoint deck. He said, “If you need more resources just say so.” I said I needed more resources. He added five developers and a development manager to the project within one week. Resource problem solved.
So the triple constraint is deceiving. First, because there may be NO constraints at all. Some companies, like my client above as well as companies such as Google, Apple and Microsoft, have a LOT of money. They can easily add scope and resources to a project. In fact, they usually do in order to achieve fastest time-to-market.
Second, the triple constraint leads some PMs to become an obstacle to achieving strategic goals. PMs all-to-frequently say no to every change request due to the triple constraint. Or they make the change request process onerous to discourage change requests.
The correct terminology is the triple trade-off. We PMs should be conducting trade-offs to ensure the project delivers maximum value to the organization. Ultimately, business value is what it is all about. Companies rarely care about scope, schedule and cost when the project is successful in maximizing business value. Trust me, no one cares if the original iPhone was delivered on-time or on-budget. PMs must know the business reason for doing a project and should base project decisions not just on the impact to schedule and cost but the impact to the strategic goals of the organization.
- « Previous Page
- 1
- …
- 4
- 5
- 6