- Or, saving time does not save work.
[Before we dive into another, great Gorilla, I'd like to ask a favor. If you find these blogs informative, please post a comment. If you find them really valuable, please tell your friends, tweet the link, mention me on your Facebook. The only way I know if my advice is helpful, is if I hear from you. - Thank you - ]
My head hurt. The stack of work before me could have doubled as a small skyscraper. No matter how hard I worked, I'd easily be pulling twelve hour days for the next two weeks. I had to find a way to be more efficient. I needed a way to speed things up, wipe a bunch of this work off my plate as fast as possible.
My eyes fell on the project training and adoption plan. It was the largest component of the communication plan for the project. It was a two hour, interactive training program that would ensure every single person involved in the project would be on the exact same page. I'd finally finished the slide deck. I'd just gotten the last sign off from the project stakeholders, that the training accurately covered all their needs and issues. I was now staring at the global calendar system in utter dismay. With people spread all across the globe (we have a coder in Antarctica, seriously?), it was going to take at least three weeks to roll out all the training. Then I'd have to compile all the questions into an FAQ, send that out and circle back with all the key stakeholders again. It was a nightmare, I'd be spending so much time on this, when would I manage the actual project?
Suddenly I had a triumphant idea. It was brilliant, it was easy and it was efficient! I'd cut three weeks off the planning phase in ten minutes! With glee I opened my email client. I found the email list I needed, Division_Head_Honcho_All_Employees, I'd send the deck out to everyone with instructions to review it and send any questions they had to me. And to save time on hunting approvals down, I'd write the email so that if they didn't respond, approval was automatically assumed.
Pure GENIUS!
<SMACK!> The banana careened off my skull and into my monitor, knocking my poor flat screen over like a high tech cow tipping.
Spinning around I shouted, "HOGARTH! What the hell was that for!"
Hogarth sauntered across the room, stopping to pick up the banana, and began peeling it. He took a large bite from the end, before waving the banana in front of my nose. "Let me ask you this. Suppose you've got one of those cute little Smart cars. You know the ones just a bit bigger than a carry on suitcase, get 43 miles to the gallon."
I nod knowing anything else would potentially result in another banana to the head.
Hogarth continued, "That is one efficient car, no question about that. But if I leave the parking brake on, or let all the air out of my tires, then no amount of gas efficiency will make that car effective."
Ah yes, the Efficiency is not Effectiveness Gorilla.
Frying eggs for my next four breakfasts, all at once, might be efficient but it surely isn't effective. And I really won't be looking forward to cold, fried eggs for the next three days.
Dictionary.com defines Efficient as:
Performing or functioning in the best possible manner with the least waste of time and effort; having and using requisite knowledge, skill, and industry; competent; capable: a reliable, efficient secretary.
It defines Effective as:
Adequate to accomplish a purpose; producing the intended or expected result: effective teaching methods; effective steps toward peace.
On the surface, they seem very similar. However efficiency focuses on the "least waste of time", while effectiveness is about "producing the intended or expected result". It doesn't matter if you complete the three hour test in 30 minutes, if you only get ten percent of the questions right. You have been time efficient, but you did not get the desired result, to pass the test.
A Practical Example:
In a previous job I was responsible for managing the program to ensure a multi-hundred person team was ready for the release of a new product suite. The team had no control over what the product suite would be, but did have to make major changes to how it did business, what tools it created/used and how its people were trained, in order to be ready for this product suite release.
The program team for this project was over thirty people spread out over more than a half dozen global locations. Team members ranged from individual technical or process contributors to heads of entire teams that would have to support the new product suite. Of these team members, none was above a senior manager role and the project sponsor was only a director. It was a challenge just to communicate with the team and the act of bringing them all into alignment and working to the same cause was daunting. At a fundamental level, the entire organization was going to have to change better than 40% of how they conducted their daily work.
Early in the project work I identified that the team was going to need proper decision making empowerment and end to end support. This required communication and buy in with well over a hundred individuals, ranging from the senior exec, of the division, down to individual subject matter experts. In an era of multi-thousand person 'corporate initiative' emails, it would have been very easy to blast out an email outlining the whole process, with a fancy hundred slide power point presentation to cover every contingency. I could have done this in less than a week and have not just those key one hundred people, but the entire division fully briefed on the project and what they had to do.
Very time efficient, and very ineffectual. Instead I spent a month focused on project initiation communication. I wrote individual emails, met one on one with people and created 'commitment contracts' from the VP on down to the SMEs. Everyone knew what their role in the project was, who they were accountable to, who was accountable to them and how communication would flow.
When the product suite finally shipped, the division was more prepared then they had been for any other release in company history. The war room set up to handle post release issues lasted only a week and was almost entirely focused on issues that cropped up from other divisions not being prepared. Quality metrics for the division, which had always gone done right after a major release , didn't just hold steady but actually improved. The division knew more about this release than any previous release. Instead of spending the first three months learning, they were ramped up from day one.
At the end of the project, four weeks of work saved countless hours, dollars and people stress. At the project start, it didn't seem to be a very efficient use of time but it was very Effective.
Being Effective:
Anoop Grover, a Silicon Valley IT project management expert, spoke at a recent PMI event on comparing Waterfall vs. Agile methodologies. At the event he said to the effect "I don't care what method you use, what I care about is the outcome. Did I get what was intended." He went on to balance this by stressing that any project must communicate clearly and often up and down the chain. At the same event, Jeff McKenna, Scrum luminary, shared a story that essentially boiled down to "Under this new model, you promise me ten features and always deliver at least nine. I also know that if you don't deliver a feature it will be feature 10. I can plan to this and know what to expect." If your senior management knows what to expect, then they have more trust, more trust makes for a much more effective organization.
When tackling an issue, ask your self what the desired outcome is. Ask yourself if the way you've been doing things is efficient or effective. Take the time to understand what your stakeholders and team want, expect and need.
You'll save time, and bottles and bottles of antacid.
Joel BC
Veteran, the Project Manager wars
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP
Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.
Posts
