February 1, 2009 – Going Covert, Part 4

NOTE: On January 12, Computerworld published an article I wrote entitled Covert PMO. This series of entries is a fictional account based on the Project Manager in that article. Any resemblance to anyone from my past, present or future is purely coincidental. To start at the beginning, jump to January 1, 2009 – Going Covert, Part 1.

Day 16, Friday – Wow! It’s Friday already. Payday is always nice. Technically it is already spent, but it is nice to have it pass through my bank account. It makes me feel like I’m doing my part to stimulate the economy.

The follow up schedule review meeting with the team went well. I wouldn’t have guessed thinking in terms of hours would be such a culture shock to them. Given the hours they estimated and their availability on my project I was able to project a realistic timeframe for delivery: 112 days. That’s a bit longer than the 83 days originally planned and certainly not happy news for Management on Monday.

I ran a couple of different scenarios, checking the critical path, and came up with some options to present to Management. It isn’t rocket science. We can (1) extend the date; (2) decrease the amount of work; (3) increase the number of resources or some combination of the three.

We’ve already been told the data is fixed. When the CEO sets a date, it stays set.

Since we haven’t finalized the requirements we may be able to adjust the scope of the project.

Adding new resources would slow us down on an already crunched schedule. Our best bet is to get more time from the resources assigned to the project.

Day 19, Monday – Meeting with Management went almost as expected. Why is it that something that seems obvious to me is a mystery to Management? Calculating the length of a project is simple mathematics. If the number hours your resources have doesn’t equal the number of hours left to complete the project, the date is going to slip.

Fortunately, after the “I’m so disappointed in you and your PMP certification” speech and then getting grilled with questions, management opted to pull my resources off their other projects. If, in fact, they are allowed to, it will effectively cut our duration by a third and place us in range to meet the deadline.

The surprise additional action they took was to add a Finance report for invoicing purposes. They need to know the total number of records sent to the Clear Mind Counseling Center. Not a big report, but I’ll put a Change Request in within the next couple of days after we estimate the effort.

The other PMs picked Tuesdays to informally get together and talk through our projects and problems. Our first meeting is tomorrow

Day 20, Tuesday – Finished off the estimate on the finance report and sent it out for approval. I wrote it up and attached it to an email, asking them to respond with an “Approved” or send it back with the reasons why not. I receive two phone calls asking what I meant: one from the Business Project Manager and one from the sponsor. Evidently the business doesn’t normally get involved at this level.

It was a great conversation starter, though. I suspect I’ve opened Pandora’s Box. After I explained that a Change Request outlines what is requested and how it impacts the cost and schedule, her interest level was raised. The business is likely to start asking for more involvement going forward.

The phone call from Management started with, “What are you thinking?!?!? We don’t send Change Requests to the Business!” I guess that was another one of those written procedures they got rid of without telling anyone in the PMO.

The PM meeting over lunch went better. Since they still think of me as belonging to the PMO, I was expected to head up the meeting. I started by recapping my first 20 days. My whining consisted of:

• No documentation on management of project including the Project Schedule and Charter.
• The fact that the deadline was set before anyone really estimated the effort.
• Requirements were incomplete.
• Lack of resources and those that I had were over allocated.
• Management status meetings more like firing squad.
• Unrealistic expectations set and held by management.
• No opportunity to re-estimate based on more knowledge of the project.

They agreed with my list and added:

• Project managers running too many projects (one guy had 7!).
• Developers adding “little” items to the project that are found in Testing as defects because they don’t match the requirements or design.
• Business not offering any input until User Acceptance and then they want to change everything.
• No agreement on requirements.
• Failing Sarbanes Oxley (SOX) related Internal Audit checks and having to rework things.
• Information Security (InfoSec) reviewing the product and demanding changes at the end of the project.

In a way it felt good to collectively get it off our chests but it left us feeling empty. Not quite hopeless, but certainly depressed. We decided to think through what we did on our own projects to address these issue and get together next week to start sharing them.

When I got back to my desk I received another curve ball. The Business Project Manager sent me an email saying there was another company they were starting to work with that offered different services. She wanted to know if we could send the same feed to another company.

Our schedule is so dead.

Jump to Part 5.

January 19, 2009 – Going Covert, Part 3

NOTE: On January 12, Computerworld published an article I wrote entitled Covert PMO. This series of entries is a fictional account based on the Project Manager in that article. Any resemblance to anyone from my past, present or future is purely coincidental. To start at the beginning, jump to January 1, 2009 – Going Covert, Part 1.

Day 14, Wednesday – Had lunch today with a couple of other Project Managers, Bill and Darryl. I told them what I was struggling with: Management expectations, resource over allocations and a project without definition. If it was sympathy I was looking for, I was going to have to look elsewhere. No surprise there. They were guys and both had complained about the same things during project reviews I had conducted.

They stopped short of laughing in my face but their little smirks were infuriating.

While washing down our $1.50 hotdog from Costco with Diet Cokes, we came to the conclusion that the processes themselves were not the issue. The biggest roadblocks were:

• Too many projects for a PM to manage
• Resources spread too thin
• Projects held to preliminary budget and dates
• Processes not communicated to the teams
• No management buy in to the process resulting in directives at odds with standards and processes

Bill mentioned that some of the other PMs had voiced similar frustrations. We decided to pick up the conversation with them.

I stole an hour in the afternoon to do a little research. My access to the PMO data hadn’t been cut yet. For the most part, PMs each had 2 or 3 projects, but some of them were running more than 5. My rule of thumb says the project management pieces alone take a minimum of 6 to 8 hours a week:
1.5 hr status meetings (15 minute / day or 1 per week) plus minutes
1.0 hr reviewing and updating schedule
1.5 hr updating the project repository and/or creating the project status report
1.0 hr risk / issue management
1.5 hr business status meetings and minutes

With 3 projects half the week is spent you’ve only covered the basics. Any requirements management, technical reviews, conflict resolution, additional reporting or stakeholder management is in addition.

In a prior life I had 3 concurrent projects. Management wanted to give me a fourth. When I presented the math to them they gave it to someone else. I like to think their respect for me went up, but I suspect their tolerance of me dropped instead.

Day 15, Thursday – Met with the team to review the schedule. I kept it somewhat high level, mostly activities and asked them to think in terms of hours, not days. It appears to be a bit of a shift in their normal thinking. I want to calculate the duration based on their availability given the number of projects they are working. They offered minor change, mostly in dependencies and half hearted commitments.
I scheduled a follow up for tomorrow and will nail it down. The rest of the day was spent estimating availability from the status gleaned in our Stand Up meetings.

Jump to Part 4.

January 1, 2009 – Going Covert, Part 1

Day 1 – It should have been an easy operation: go in, implement the update and get out. But it was anything but easy. It led to the Incident. Years from now I’m sure the Resource remaining with the Company may laugh about it, but this week the PMO was hit hard. The Head was chopped…gone. They pulled rank, brought her a box to go with the termination speech and brought in a Yes Man.

It may have been better if the whole unit had been pulled out. At least then we could land somewhere else and possibly do some good.

And this was supposed to be the year everything went right.

Day 2 – Made it to Friday without suffering the fate of the Head. I’ll regroup over the weekend and start fresh on Monday.

Day 5 – Overheard joking in the Development quadrant this morning. Someone said the Head had it coming. Overstepped her bounds and tried to call the Management to task for not following the Processes. IT’S A LIE! They were waiting for her to fail. Then they were all over her like flies on road kill. Stupid thing is we tried to warn her, but she didn’t see it coming.

Now the shuffle starts. I’ve been demoted from the PMO and reassigned to the Project Management squad. I knew too much to stay in the PMO but not enough to get rid of me completely. The patsies they are putting into the PMO certainly won’t push too hard or ask the wrong questions.

I’m ok for now. Gotta keep my head down, do the Job. It’s been a while since I had a full time PM roll, but I’m sure it will come back quickly.

Day 6 – Looks like I’m heading to the front lines: high profile, troubled project in the heat of battle. I suspect when he handed me the Binder, Management wanted me to think the smirk on his face was congratulatory. It wasn’t. This is a win-win for him. If by chance I survive and win the battle, the Company profits. If I fail, Management has a ready made reason to push me out. It would probably make him happy if I pulled the trigger on my own.

Day 8 – Been looking through the Binder. The previous PM didn’t do much. We’re supposed to be in Design, but there isn’t any evidence that the Requirements are complete. The Schedule looks like someone took the template and blew a big hole in it before throwing names against it like rotten vegetables at that house down on 3rd street. Not pretty.

Based on the Charter…which was never approved…we have a deadline. No real objective or clear direction. Just a deadline.

I’m assuming the previous Project Manager won the lottery…or got another job. Haven’t even heard what his name was.

Did meet the Team, though. Some of them seem pretty sharp.

Day 9 – It’s Friday again. With a long weekend of Planning ahead of me I suspect I won’t get much sleep. Entering the sleep-depravation phase. I wonder how long before the water-boarding starts.

I made the connection today. This is the project the PMO wasn’t allowed to review. It was stamped “Critical” and encouraged to “not let the Processes get in the way of progress.” Looks like it lived up to its calling because it did go critical…nearly nuclear.

And now it’s all mine.

Jump to Going Covert Part 2.

NOTE: On January 12, Computerworld published an article I wrote entitled Covert PMO. This blog entry is a fictional account based on the Project Manager in that article. Any resemblance to anyone from my past, present or future is purely coincidental.

September 29, 2008 – Back to the Basic: Communication - What

While waiting in line at Costco to buy my $1.50 hot dog and soda, I watched the manager collect money from the tills and seal it in plastic, oblong containers. He walked over to the wall and stuck them in a pneumatic tube. With a muted *phoomp* they shot up and out of sight.

Long before email, the quickest form of interoffice communication was the dial switch message tube. Plastic cylinders were sucked from one end of the building to a central switch board. From there they were placed in another tube and pushed to their destination. Instead of having a megabyte size limit for attachments there was a weight limit.

Given the length of time that people have been communicating, the topic of communication is obviously huge. Methods have evolved from papyrus to paper and are headed to paperless…which just seems to create more paper. Communication is concerned with the entire package: what to communicate, when to say it and how to deliver it.

What to Communicate. Simply put, as a project manager you need to communicate answers, accolades, applause, bad news, budgets, briefs, causes, critiques, costs, delays, dangers, decisions, earned value…and I’m only up to the Es!!! An estimated 80% of a manager’s job is communication.

So how do you know what to communicate? That depends on who needs to know.

Delivery Team. To the team you need to articulate the vision and direction of the project. Begin with the defining documents (Charter, Scoping Document, SOW, etc.) to lay out the vision of the project. Use the Work Breakdown Structure (WBS) to drive discussion of what needs to be accomplished and how to get there. Set delivery expectations by laying out a schedule with assigned resources, specified effort, and agreed upon dates.

Since communication is a bi-directional exchange, require feedback. Collect status, effort, re-estimates, criticism and suggestions. Don’t accept excuses, complaints and whining without moving them beyond to solutions.

Sponsor / Management. Contrary to popular belief, management does not always want a rosy picture painted for them. They need the truth told succinctly so they can make informed decisions. They also need bad news delivered as soon as possible so they can take action.

On the other hand, management, if left to their own devices, will make assumptions that may not be true. Understand their expectations and work to align them with reality. Based on the scope definition of one project I was on, we successfully upgraded a software package. The directive for Phase 1 was “out of the box” and we and held the modifications to a minimum. At the end, the sponsor was disappointed she didn’t get the new reports she wanted. I had failed to keep her expectations focused on the scope.

Governance / Auditors. The job of the Governance (Program or Project Management Office) and Auditor groups is to ensure that the safeguards are in place to make the project a success. They want to know that you understand the processes are following them. If your project doesn’t fit the mold, meet with them up front and carve out a new mold that everyone can live with. Communicate lessons learned and process improvements to make projects work more effectively.

End Users. Usually End Users are ignored until the product is virtually complete and then they are brought in to ooh and ah over what we created for them. Your job is to understand their expectations from the inception of the product, align those expectations with the development, confirm them in the User Acceptance Testing and deliver successfully. Communication is the key through each of these steps.

Others. There are always others. Some of them can kill even the most successful project. While speaking with my PMO counterpart on a mass transit project, I asked who was handling the communications to the ultimate end users: the people taking the trains and buses. The project was to implement smartcard technology into the public transportation system. If they were unprepared to use the system, it would be a failure. Who will be impacted by your project and how should you be communicating the changes to them?

The ultimate purpose of communication is to eliminate surprises. Do that and you will be communicating the “what.”

May 12, 2008 – Stop Wasting My Time

My brother-in-law, Paul, tells a story about a boy, Theo, who wass afraid of clowns. The tale follows Theo’s life from childhood to teenager to young man through to his old age. At different stages in his life he attempts to survive a circus performance but always ends up fleeing, screaming hysterically, at the sight of the clown. He tries therapy, hypnosis and other extreme means to cure himself. Finally he joins a religious order of monks known for their fearlessness and sharp comebacks in the face of danger. In the final confrontation with the clown, Theo is being chased, stumbles and falls down. With the clown standing menacingly over him, Theo finally faces his fear and yells, “I don’t like you very much!”

Quite pointless, eh? Paul can drag this story out for at least 15 minutes, adding more details and deeper insights. When he finishes you feel cheated out of a large portion of your time.

As project managers, we need to make sure that what we are asked to do has purpose. The Systems Development Life Cycle is a great example of this. As part of the Project Management Office, I expect pushback from the people using the SDLC. The majority of the templates and processes come directly from the teams, but if they don’t make sense we need to get them changed. In order to be successful, everyone needs to get involved in the following ways.

Know What. Keep an eye out for PMO announcements telling you what has been added or changed. When you start a new project or phase, browse through the processes, templates, best practices and lessons learned to make sure you have the latest and greatest. The temptation is to modify what worked for the last project, but great improvements may have been made since then.

Understand Why. I’ve been guilty of playing the PMO blame card. Early in my PM career I would ask the team or client to complete something “because the PMO requires it.” A great example is the Risk Assessment. If you are just filling in risks because you have to, you are missing out on a project saving devise. Telling the client / business that you have to have one to pass an audit may get you off the hook immediately, but it shoots an arrow into your support team. Eventually the client / business will think all PMs blindly do whatever is dictated. They then loose faith in the whole organization.

Use Them. Put the process to the test. Processes and templates generally aren’t built to gaze longingly at. They make really lousy wall hangings and lawn ornaments. They are intended to be used. Besides, the best and most constructive complaints come from those that have tried to use them, not those that ignore them.

Provide Improvements. The goal is to use the group’s collective knowledge and learning to continuously refine and replace what exists today. The PMO will be among the first to admit that the best answers come from the line. Toyota’s manufacturing success has at its core the right and responsibility of assembly workers to suggest ways to make it work better.

The users of the processes are the real owners, not the PMO. If a piece is broken, get it fixed. If it doesn’t make sense, find out why it even exists. If no one knows why, get the PMO to drop it until someone screams for it back.

In the end, no one wants to waist your time with pointlessness. Well, except maybe my brother-in-law.

February 19, 2008 – Welcome Aboard!

"Welcome aboard!" is, unfortunately, the only orientation some Newbies ever receive when starting a new job. If they are lucky someone shows them where the restrooms are...and how to find their way back. I can’t say how or why it happened, but I recently heard that a new project manager, on his first day, excused himself to use the facilities...and never came back. If you want to retain resources longer than a couple of cups of coffee, the PMO or department management should create a new hire initiation that covers the following areas.

People. Get them connected to others. An Org Chart helps. My biggest fear when starting in a new location is that the CEO will greet me in the hall and I’ll say something stupid. I can picture myself saying, "Must be great to be management and take all the prime parking spots!" Walk Newbies around with the Org Chart in hand and at least give them chance of not making fools of themselves. If possible, get a group to take him out to lunch and pay for it.

Access. A list of all required system, application and building accesses should be maintained. Prior to the Newbie showing up, make an effort to get the access set up. Add them to all of the distribution lists they need to be on. Extra Credit: Add to the list a paragraph or two describing what each system, application or building is and why it is important to them.

Tools. With great access must come great understanding. Too dramatic? Probably, but you need to know what tools are available and how to use them. Timesheets are a great example. Are employees required to complete one? How many different places is time recorded? When is it due? Oh, and how does it work? Make the documentation available and, when possible, step them through the first use.

Processes. For those of you who feel oppressed by process, be thankful you have one. Trying to run a project in a chaotic environment is worse. It is like hacking your way through a jungle with no paths. One client I was working had two IT departments: one had a well established process and the other took a more "whatever it takes" attitude. Several project managers moved from structure to chaos, thinking they were finally free. Within a couple of weeks they were calling back for templates and direction. They were drowning in their new found freedom.

Meetings. Every environment has a standard set of meetings that happen. In mature environments a Communication Plan exists that spells out each one along with its purpose, attendees, location, time and frequency. If the plan doesn’t exist, at least make sure they get sent the meeting invitation in time to attend the next one. Let them know what meetings they are expected to establish for their project. Is there an overall project status meeting? Does each area have their own? Are daily standing meetings the norm? Who handles the status with the Business? Is there a Steering Committee? Lacking direction some toes are likely to get stepped on.

Reports. From status to metrics, management doesn’t communicate without reports. This, too, is usually covered in a Communication Plan. Each company seems to have a different expectation for status reporting. Some obtain status information verbally at meetings with the team. Others expect everyone to produce a status report. I’ve seen several companies switch to a 4-Panel status approach (example: 1-page with 4 quadrants: Status, Financials, Schedule and Risks/Issues). Again, if the Newbie doesn’t know, someone isn’t going to get their expectations met.

Locations. The company I am currently working for has several buildings multiple miles apart on the same highway. When I first started out I would get meeting invitations for the "Large Conference Room" and end up in the wrong place. Let Newbies know where the different branches are, the best places to have lunch and how to decipher the meeting room locations. One place I worked used the names of different beaches for conference rooms. Cute idea, but where is Malibu in relationship to Laguna?

I would wait until last to mention the restrooms, though, just in case the Newbie gets the urge to check out and never return.