ClearPM

Project:

Server refresh for online document sharing/management system.  17 physical servers need to be replaced with new ones and 3 virtual servers need to be implemented.

Customer: 

Internal organization responsible for operation of the system

Status: 

I was assigned as PM on this project at what seemed like the beginnning.  Nothing was documented yet -- no scope, no charter, nothing like that.  The customer knew what they wanted to do as a result of discussions with the application vendor, the age of the old servers, and the performance of the old system.  Although the customer had planned to complete the server refresh themselves, they realized they didn't have the time to devote to the effort so they decided to bring in a PM from outside their organization whose only role would be management of the project.

Action: 

After discussing the status with the customer, I set about identifying the other team member roles I would need to fill.  One of those roles would be a system administrator to build our servers and put them into operation.  The customer already had a sys admin on his "payroll."  This admin worked with the customer daily and funding was already allocated to his department to cover his labor expenses.  OK, I thought, one resource identified.  That makes things easier.  I continued to build the small team, began holding meetings, building a schedule, documenting requirements and design, and the project started moving forward.

While creating the schedule I spoke to the system administrator to get estimates on how long it would take him to do the work.  He also notified me that he'd be on vacation for four weeks over the holidays so I scheduled around that.  The customer coordinated on project-related matters throughout the week.  The project was proceeding in an acceptable manner.  Last week I called the sys admin to find out if we might be able to find anther admin to fill in for him while he was on vacation. 

"Well," says he, "it's normally Juan, but Juan will be on vacation so maybe Mary or Tom can fill in but they have a lot of other work to do so I don't know if we have anyone who can fill in."  A warning siren was beginning to warm up in my head.

"Well," says I, "who's your manager?  I'll ask him/her who your replacement will be during your vacation.  That's why managers get paid the big bucks."  He gave me the name and I dropped the manager a line in an e-mail.

The response I expected was either "I have a replacement and here's their name" or "I don't have a replacement so you'll have to wait."  What I got was, "Refreshing servers is completely outside our statement of work.  We do application support and in no way can server refresh be construed as application support."

Wow.  This project had been going on for weeks and weeks and I had spoken with the system administrator and customer on numerous occasions and there was never any hint that my team member was not supposed to be doing the work he was on the team to do.  This was completely unexpected!  If this turned out to be true, I was going from a short delay as the new sys admin got up to speed, to a 4 week delay if we can't find a temporary replacement, to a potential 60-day delay if we have to develop a new statement of work, route it through our corporate bureaucracy, and get a response from our internal provider.

Today I'm still waiting for a ruling on this issue to find out my next steps.  If the server refresh is considered part of the sys admin's statement of work, I need to find a replacement or wait until the guy returns from vacation.  If it's not part of their statement of work, I need to start processing that paperwork to make it part of their statement of work.

What Could Have Prevented This?

Option 1:  Take the time to verify the team member's availability and role.  This could take the form of a more in-depth discussion with the team member.  In this case, the system administrator was already performing server support tasks and did not understand that server refresh was not part of his job.  Talking to him more would not have uncovered this issue.  And if I take the time to verify the availability and role of every team member on every project by talking to their managers, I'll never get anything done.  I don't think there's a good or easy way to determine which specific team members I should verify before proceeding with a project.

Option 2:  Develop a template that describes the work each team member is expected to accomplish, where the funding for their labor will come from, when the work is expected, etc.  Most of this just isn't known at the time the team is being put together.  The PM has to rely on the team members themselves to identify a lot of this.  Maybe this could be a "living document" with basic info when the project starts but more completely filled in as the project progresses.

Option 3:  I don't know what option 3 might be.  I'm open to any ideas! 

To me this situation is a result of the administrator not understanding his own responsibilities and the responsibility for that education goes back to his manager.  It all makes me wonder about this one critical resource:  If this project had taken place at a time when the admin wasn't going on vacation, would this issue have come up?  Would the admin have proceeded with the server builds?  I suspect he would have and nothing would have been said.