Free Newsletters

   All InfoWorld Newsletters
Advice Line | Bob Lewis » Join a challenged project or not?

May 23, 2006 | Comments: (0)

Join a challenged project or not?

Dear Bob ...

I am systems engineer and architect and recently have been offered a position with the architecture group of a large-scale information systems project. This project is about halfway through its contract period. It has been late on its first few deliverables, and its next deliverable will also be late. There is evidence of serious scalability problems. The top three levels of project engineering management have been sacked, and new people brought in.

I spoke to the project's new Chief Engineer. I asked him questions about what he thought the problem was, and how he intended to deal with them. His answers always had to with more and better engineering  He never mentioned requirements.

This is a very large-scale project, with a lot of parts that were not designed to work together that need integrating. I believe that requirements provide a convergence point for multiple independent integration efforts, a "forcing function" that increases unity of effort. If the top of the food chain doesn't understand this, then I would have to convince them that this is true before any useful work could be done. I don't think I have sufficient time to do that on this project.

I know that when the stuff hits the fan, it tends to stick to everybody in the room.  I think I could add value to this project. I could perhaps keep it from failing, even if I probably can't make it a great success.

My question is this: is it possible to join up with a project like this and not have it hurt my career?

- DANGER/opportunity

Dear In Danger ...

While I generally don't use the term "requirements" (it's lost most of its meaning: I prefer to ask business users, "How do you want to run your part of the business differently and better?") it appears we think along the same lines. You can't design or integrate anything when you view it as solely an engineering challenge.

So to answer the question you didn't ask, I'd advise staying away from this project. Engineering is difficult enough when everyone understands the point of it all. Without that, a project that's already behind schedule will almost certainly deteriorate into unresolvable arguments whose source is misalignment of core assumptions on the part of the arguers.

To answer the question you did ask: Sure. If the company that contracted to deliver the project is run by reasonably intelligent executives who recognize the value of an employee who manages to bring into port a ship that by all rights should have sunk without a trace, there's a lot of opportunity in a situation like this.

There's also a lot of risk, since the more common response among executives who are dealing with a highly visible mess is to "hold people accountable" - managementspeak for "find scapegoats and publicly hang them."

- Bob

Posted by Bob Lewis on May 23, 2006 06:05 AM


RATE THIS ARTICLE:





 

  •  
  • COMMENTS




A few years ago I was assigned a project like this. If I'd had a choice I would have stayed clear of it. It was handed to me with the sales tag of "This is a sinking ship, you make it sail you're a hero, if it sinks, no one will blame you." I won't say that this ship actually sailed, but it floated. My department delivered every piece we were responsible for to spec and on time and succeeded for our purposes but the project finally ended grossly behind schedule and over budget. In the end, my department was one of those targeted, which effectually meant me, as the cause of most of the delays and short comings of the project. How this happened when we were always on or ahead of our schedule I'm not entirely certain, but I ended up leaving the company after my management refused to support me and let our group (i.e. me) take the blame for this failure. My next annual review was filled with inaccuracies detailing poor performance on this project and indicated that I would not receive a raise because of it. I produced the documentation (test dates and sign-offs by business partners) to show this information as inaccurate and refused to sign it, until it was amended. In addition, one of the primary project leaders was "asked to resign" due to her inability to manage projects effectively. Her comments were some of the most damaging on my review. In the end, I simply left the company. Since then I've found that all but one of the "Leaders" of this project that slammed my group and me on our reviews are no longer with the company. I wonder why. Good luck.

Posted by: Troy at May 24, 2006 11:30 AM

Three books. Three ways to change the world, your life, or at least Bob Lewis' bank account.

Leading IT: The Toughest Job in the World distills the world of IT leadership into eight learnable skills and gives you concrete, practical techniques for each one of them.

Bare Bones Project Management: What you can't not do makes project management manageable, even for first-time project managers with no formal training in the discipline.

ManagementSpeak: What managers say/What they mean … well, it won't help your career, and won't make you a better manager. Mostly, it will make you chuckle, guffaw, and maybe even chortle. Make friends - it's the perfect gift for anyone who has ever suffered through one of those meetings.

Order your copies today!





Technology White Papers

 

InfoWorld Technology Marketplace

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert

Find out when the latest white paper is available:
 
 
» BUY A LINK NOW

Sponsored Technology Links