IT and Project Management Consulting
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.
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.
Email is an example of a push communication. It is pushed from a person to many people. There are three problems with push communications:
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.
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).
I’ve collected a lot of project sayings over the years. Many of them have to do with planning, including the first:
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:
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:
And my personal favorite:
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:
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).
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.