Project Managers as Contractors is the WRONG way to go!

Everyone knows that project management in today's organizations is essential to business success. Without projects, you don't accomplish new business objectives. The discipline of project management is your best bet in reaching those objectives.

However, there seems to be an upward trend to hire project managers on a temporary basis to run these projects. I've seen it in my own organization and I've seen it with ex-colleagues who have gone on to take contractor positions in firms for the life of a project.
Indeed, the August issue of PMI's magazine PM Network has an item about this in The Buzz. Click here to read it.

One sentence says "...the temporary nature of projects makes them particularly good candidates for contract work".
This is quite true. It does seem like that...so what's the problem?

The problem is that effective project managers should be in place longer, much longer than just the life of the project. They are the ones that should be there permanently! PMs have more clout, more influence, and talk to more people than anyone else on the project. Their reach extends far and wide. Would you really want to lose all that after a project is finished?? If you find an effective PM, you keep 'em!

The ramp-up time for a new PM to be effective can be very long. For the PM to learn what makes their stakeholders tick, how to influence each and every one of them, to build relationships with them, along with the BAs, with the people doing the work, etc takes a very long time. The hub at the center of the wheel is difficult to replace.

So I've made my point about keeping PMs for the long-term. But what do you give up in this kind of environment where contracting is the new norm?

The solution is: The line positions that executes should be turned into contracting positions. Developers, architects, QA, support staff, for e.g.

If you have a strong PM & BA who are intimately familiar with what needs to be done, they can train new people to do exactly what they need them to do to accomplish the project goals. Especially with newcomers to the organization, it is important to get them off to the right foot and train them in the way you want things done. Then they will be able to deliver. We have a new QA person in Singapore who I will be training in our application. I will spend some late hours with him to get him up to speed but I will show him exactly what he needs to know. I don't mind doing this, because the payoff will be immense.

There is more of an impact on an organization's capability to deliver if you lose a PM vs. any other position. In my own case, I have been delivering in my space for nearly the last 2 years, and I have the confidence of the people around me that I am true to my word. This makes it easier for them to trust me and approve things. A new PM would have to build these relationships from scratch.

Furthermore, in today's agile world, no position is safe. If you're not advancing and continuing to build your skillset and your relationships, you're in danger of losing your job. Indeed, in the very same article, there is a quote, "When I hear people talk about temp versus permanent jobs, I laugh. The idea that any job is permanent has been well-proven not to be true."

So why should a developer who knows how to code a certain financial module (for instance) be so secure? Some people may think they have job security because only they know the module. However, if they're not performing, they should face the consequences, not be given free reign.

Plus, I'm willing to bet that a good developer or architect who comes fresh into a job and is given a mission (I need you to do x, y, and z and figure out how to do this) will see this as a challenge and figure out how to get the job done. Indeed, in my role as a BA on some projects, one of the pleasures I take is in coming fresh to a project and piecing together the puzzle of what needs to be done... This way, I start to own it.

Good, Cheap, Fast

At my local bike shop: They got the triple constraint down pretty well!

The Invention of Process

Just finished reading "Rework"( Link to Rework )

As usual, class-A material from people who execute well. They have their act together...truly. I love the fact that their goal isn't to cater to the Fortune 500...they cater to the Fortune 5,000,000! The know where they stand and that's where their power comes from.

There's a chapter towards the back about Policy, and how in many instances, policies are "codified overreactions to situations that are unlikely to happen again." I totally agree!

This brings to mind a quote from a book that I read a long time ago on the making of the atom bomb. Edward Teller, a Nobel Prize winner and father of the hydrogen bomb, was advocating the use of a bomb on an asteroid as an experiment. Someone remarked, "If you've got a problem, Eddie's got a bomb!" Basically there were a lot of idle bomb experts sitting around after the war ended...

Well, the same holds true for process: If you've got a problem, [Insert Name here] down the hall has a process". The proliferation of processes is something you've got to watch out for. Several things can happen:

1. The process is actually too cumbersome, and people circumvent it.

2. It leads to a false sense of security that everyone is doing the right thing and that they're delivering quality software because all the i's are dotted and the t's are crossed.

3. Following the process doesn't mean you're even delivering anything of value. To be zen here, "Like the finger pointing at the moon, the finger is NOT the moon". Likewise, following a process is no guarantee of anything. It just means that some auditing team can catch you if you didn't upload some documents in a timely manner.

Ditto for templates...