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.