First Week on the Rescue Project

It’s your first day on the project and although no one said out loud you need to rescue the project, you do. There’s a reason there’s been a switch, and most of the time people will be too polite to say out loud that your predecessor was failing. So here’s how to get started:

Don’t Read The Scope of Work

That’s right. Do NOT read the scope of work. There will be plenty time for that later. But the problem isn’t the scope of work, it’s that no one else really read it either. So here’s what you do instead:

Think of the project like a multi-layered cake. On the bottom, you have developers and QA folks – they’re doing the real work. Next layer up is the product or project manager. They think they’re doing the work. And the top layer? That’s the person writing the check. Sure – you can slice this into more layers, but 3 should get you started.

Meet with as many people on the bottom layer as you can, and ask them what they are doing. Don’t let them fetch the scope either, and make it conversational. Take notes.

Repeat with the middle layer. Take notes.

Finish up at the top. You can probably see where this is going already: the person writing the check thinks one thing, the product manager a second thing and the developers a third. There you go. That’s probably why your project is in crisis.

Figure Out How They Do Their Work

You have two broad categories here, Agile and Waterfall.

If it’s a waterfall process, find a whiskey barrel, get in it, and throw yourself off a cliff while holding a Gantt chart. You’ll have about as much success managing the project as surviving the fall.

If an agile process, your odds just went up. But you’ll want to know a lot more about what their version is really like. Do they say agile but mean waterfall? Are they actually delivering code to production at the end of each sprint? Those things matter, and they’ll help you understand how things are actually working. The tug of war between methodologies is strong, and even the most agile of shops can get pulled into waterfall processes and procedures. You won’t be able to change those, but if you understand, your odds go up.

Understand Their Technology

This can be challenging; your job isn’t to do the the actual work – but you should understand in broad terms how the project team is going about theirs.

  • If it’s a website project, you’ll want to know what tools they use to generate graphics, what technologies are in play on their live website (HTML, CSS, JavaScript and a lot more, probably), how they host their website (on premises, with a vendor, in the cloud), and how they publish changes.
  • If it’s a database project, you’ll want to get answers to the same questions about where (on premise, hosted, both) as well as to know the fundamental tools (SQL, MySQL, Salesforce, something else).
  • Mobile? Even more fun. What devices, what operating systems, what handsets, which app stores and so on.
  • Infrastructure? Swell. Domain names, routing, switching, fail over and redundancy and so on.

Again – you don’t need to be a domain expert, but you need to know the building blocks of the project you are managing.

Understand Their Culture

There are entire books written about this, and about how culture is perhaps the most important thing to know and understand at a place of business. You won’t be able to absorb it all right away, but you can ask yourself a few questions to get a sense:

  • Are their motivational posters on the wall?
  • Are people afraid to disagree with one another (or worse) their boss?
  • Is shoddy work tolerated?
  • Are people rewarded for following the rules?
  • Does your tech team sit far away from everyone else?
  • Does everyone come and go at the same time?

Here’s a shortcut: if you were looking for a full time job, and they offered it to you, would you really want to say yes? That’s a good sign. No? Not so much.

Now Read The Scope

You’re still in the first week – take a look at that scope. Make a copy for you, and mark it up. You may as well get the latest budget numbers and date estimates, too. Don’t get me wrong – those are all good things to know, and you’ll need to track those carefully to be successful. But merely tracking those things won’t make you successful – you need the other things on this list to do that.

There you go – a task for each day of your first week on the rescue project.

Looking for more tips? Try these on for size:

Patrick’s Top 21 Project Management Tips

What Makes Great Project Management Software?

Becoming a Technical Project Manager

Sent Your Iron Triangle to the Scrap Heap

Waterfall or Agile?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s