The Rookie and I

I was actually going to call this How to train a project manager but decided against it because it would probably raise such universal questions as 'Can you really train a project manager?' So, herein I present the almost neverending saga of project managers and IT professionals.

Project management... Some think of it as an artform, others think of it as irreverent and pointless, but all agree that it often is a necessary evil. I am not going to debate either side here but just present some experiences albeit embellished of project management in the IT world. A lot of the experiences sound remarkably similar yet so different which presents a dilemma when cataloguing and classifying them. So as the author of this blog, I have taken the liberty to classify by project manager, as after all this is the key determinant and differentiator in all the projects.

The Rookie: A project management virgin for lack of a better term. Often thrown in the deep-end without actually being told how deep the pool actually is but also without being taught to swim. Thus, the onus is often on the other project team members to train and manage the project manager. As if this wasn't complicated enough, this also involves managing not only the person but the EGO. Often (and not always) you are dealing with someone who is not only underprepared in managing the project albeit the team but also doesn't realise it. A bad workman may blame his tools but first he has to actually have some. Better still, they often have a supreme confidence in their abilities where they actually truly believe that they are managing the project people. As much as I hate to admit it, that is what they should do but the clincher for me is their management style. Without the necessary tools in hand and experience to draw on, they are forced to rely on the Command and Control approach (to quote Joel Spolsky). What I like to call the kindergarten approach - I am bigger than you so you have to do what I say. Not an ideal way to manage kindergartners, let alone an IT project team. Especially in the IT world of today when one project makes you the team lead and the other makes you part of the development team. There are almost always going to be more experienced people on a team. The problem the rookie faces is he doesn't realise how to manage this. Again, the kindergarten approach - I am the 'boss' so I should tell them what to do. The net result often is that the project members either get frustrated, infuriated, insulted (often all of the above) leading to a lack of confidence in the project manager and either non-cooperation or a power struggle. Net result: IT project disaster in the making.
I don't mean to say this is always the case or that the other team members are not in any way contributors to the potential failure of the project, but having project management issues certainly doesn't help!

Build it before they come...

The Global Sourcing phenomenon has really taken us (in the IT industry) by storm. There's no escaping it and in my opinion an organisation would ignore it only at their own peril. It has become one of the key strategies in the game of staying alive let alone ahead in the IT market. In an earlier blog, I bemoaned the lack of ownership within an organisation for the failure of outsourcing - the fact that often employees don't see how it benefits them. To some that may sound very philosophical and (dare I say it..) HR speak.

Another more concrete or tangible reason is the logistics. Before I go into this let me just digress (again...). My perspective on outsourcing and it's implementation comes from an application development background, so needless to say that will be my focus. Let's consider the scenario...

An organisation decides to descend down the road of outsourcing. What's the easiest thing to outsource? Often the so-called back office functions; development and testing. The theory (often heard by many) is this; development and testing work is partitionable (for lack of a better word). You slice of blocks of your project and pass it to either the test or development teams and at the end of that timeframe (in your project) the work magically appears done. Classic waterfall model and it lends itself (in theory) as an ideal candidate to Global Sourcing.

This does of course include several assumptions.

• The piece of work is well defined with clearly outlined start and end criteria. In the case of development, this is well defined requirements documents (with no potential for scope creep - I just noticed all the developers glaze their eyes over on that, but bear with me..) and in the case of testing, a complete unit of software that is ready for testing again with clearly defined documentation.
• Minimal micro-management of teams. The project manager would only require updates on progress and otherwise everything will continue as is.
• Communication between the various teams will not be an issue. This includes accounting for time zones and geographical diversity.
• All resources required by the various project teams will be readily available and accessible.

There are many more to this list and all if not most are easily rectified. The key is identifying these issues and working through them. There needs to be a willingness and acceptance of the issues and risks associated alongside them. To think that a seamless transition will occur is setting oneself up to fall a long long way down.

But I digress... back to the logistics. The biggest thing from a purely logistics perspective for outsourcing is the geographical diversity. That which is it's biggest advantage can also be it's biggest disadvantage. Your teams may be at the antipodes from each other. Not only does this hinder face-to-face discussions but something as simple as the time difference can cause an issue. One group will work while the other sleeps and vice versa. The positive spin is that you can have work on the project close to 24 hours a day. Conversely, you have a 24 hour turnaround in responses between teams and potentially team members. You may have someone work on a project for a whole day only to realise that they are operating on a completely different tangent to another team member. This coupled with communication (as in being able to contact team members when required and not language) pose potential roadblocks on the path to outsourcing success.

Another side of the logistics is the infrastructure...

To be continued...