Another great week. After a long and relaxing weekend, we got right back into the flow. The biggest thing this week was the discussion about the significant differences between what was estimated and what is needed. A common project issue, but this one was recognized early, and the team has taken steps to address this now rather than wait until it becomes a crisis. But that is "project" stuff. Program Management Stuff: The challenge of building a methodology and framework continue. I need to merge at least two well-developed methodologies together and customize them for this type of program. Both methodologies have a lot of SDLC (System Development Life Cycle) components and are obviously IT-centric. This poses some challenges since there will be a great deal of non-IT work to be done. I will probably get all the details on this in the coming week and have some specific items to dig in to and relate. In the area of documentation/deliverables/artifacts or whatever they are calling these today, there is a wide variety of quality and quantity. My thought here is to concentrate on what can be reused and what is unique to the program. In this area, the schedule figures prominently. With multiple projects feeding into six main programs, there are a lot of schedules out there. Well, that is not exactly true. There are some schedules out there, some spreadsheets, some word documents, some post-it notes and some good memories. My challenge is how do all of these inter-relate and how do we track this. There have got to be thousands of tasks being managed by 20 managers, how to get them all to feed information int a joint schedule? Well, honestly, I do not know yet and suspect that I am going to find out. My current plan is to work down from the key dates and deliverables. I think one "summary" or overall schedule will be used for communication with the sponsors, customers and ourside stakeholders. There will then be one schedule for each customer (2) that will be split into either 2 or 3 sub schedules each representing one of the key programs. Past that, I don't think the PMO will be involved in other than helping each of the program managers in organizing and collecting their schedule information. It is likely to be very different for each group. So far, this sounds pretty simple, so I am sure there is something I am missing. Basically mirroring the
Communication: As we all know this is and will continue to be a key. My thought here is that my first job is “seek to understand.” I do not see how I can provide team members with the information that they need without understanding the team members themselves. For this I am convinced that nothing other than personal contact will do the job. I think you may be able to like and work well with people that you know over the phone or email, but that we can’t build the level of trust necessary without a personal relationship.
For this my approach is to do some traveling, probably a lot of traveling over the course of the program. I expect that only by meeting and working directly with the team members will I understand what is important to them and their communication and behavior styles. There is a lot of work involved beyond the traveling. I hate classifying people; we (people) are too complex and too adaptable to be classified. This makes it impossible to me meet once or twice, pigeonhole someone and then stick to that for the length of the program. What I need to do is to “understand” the people I am working with, how they relate to me, the work, the environment, the company, etc.. To do this is going to require that I be very open and vulnerable. I plan to invest a lot of myself in this work, if I didn’t how could I expect anyone to trust me?
Communication is not effective without trust. Trust requires a lot more than a few visits and come handshakes.
Sunday, September 10, 2006
Subscribe to:
Post Comments (Atom)
1 comment:
Hi Derry - great entries on building a PMO! This would be a great topic for a PODCAST! Know anyone you can do a podcast with? ;-)
Post a Comment