PM Work: Some Required Assembly…

Haven’t had much to say about Program Management in a while so decided to talk some stuff I ran into at a recent  ScrumMaster seminar.

Now I love scrum as much as anyone.  You got your Chickens and you got your Pigs, and who isn’t going to love a PM method that’s got roles based around an old vaudeville sketch about farm animals right?  Okay… so I love scrum as a method of project management for other reasons than that – but lets face it that is pretty bizarre. 

Now, it’s all really cool to have this great method to reduce time to product, reduce costs and increase quality.  And it’s all great to use agile methods.  But the fact is that Scrum and Agile aren’t for every project and they’re not for every team. 

They are not a one-size-fits all method of development but they’ve become very much a defacto standard for everything and used without really a lot of good reasons other than the teams involved have used them before they worked.  Which is a good reason to try, but that doesn’t mean that because it worked once it’s going to work again.

My daughter has a car.  It’s a great little Berretta and it’s very old.  Now, I used to have a really great Turbo Capri from about the same year as her Berretta and when it gave me fits, I replaced the starter and it worked well.  Unfortunately, my Daughters Berretta has a problem with it’s ECM and replacing the starter isn’t going to help it.  It needs a new ECM and it won’t matter whats worked for me in the past.

  So before I go into a project and decide that Scrumming it up is a good idea I need to talk to a few people. 

I need to talk to the people who are going to work on it.  I need to talk to the people who are going to pay for it.  I need to talk to the people who are going to use it.  I also need to talk about if it’s even remotely possible.

Basically before I can even decide on if I want to be in the project - I need… Project Requirements. 

Which is something I’d like to toss out there as a PM and a process I’d like to talk about.  When people approach you with a project you need to really understand all the requirements of the project itself. 

Now, not everyone who’s a PM is in a position to pick and choose their projects.  But even if you didn’t get to pick your project(s) you should do this every time you have a project dropped on you.  If you’re going to drive a project then you need to know everything you can about it. 

When I start a project I personally go through this.  I sit down and I write up, for my own understanding in a very rough outline form, the project General Requirements. 

My general requirements list is everything that are currently defined requirements that are known.  This is the starting point and from there I can determine the questions I need for my other lists.

I’ll create a short Systems Analysis, and in this I’m going to include all the things I can find out about what are the specific systems requirements I can think of and find out.  If the General Requirements have a preference  for a particular kind of programming language or a technology – I’ll hit the internet and write up the known specifications needed for that technology so when I sit down and have meetings for the real Systems Requirements I not only can understand what I’m being told but can actually participate in the discussion.  Here I’ll include anything I don’t know –all the questions that I can’t find answers for -  which are just as important as what I can find out, what I can know. 

Next I’ll move on the Functional Analysis and then the Design Analysis.  I’ll break it down something like this: 

• System Analytics are about the physical properties needed to make the project happen.
  • What technologies?
  • What physical products will be needed?
• Functional Analytics are about what it will actually take to make the project happen.
  • Do we need a lot of people to create this? 
    • What kind of people?  Experts?  Developers?  Designers?  Manager?
      • How many Pigs?  How many Chickens? 
      • Will we need Silverbacks or just Codemonkeys?
• Design Analytics are about we really are trying to create.
  • Is it about quality and style?
  • Is it about ease of use?
  • Is it about cost?
  • Is it about doing something no one else has?
  • Who’s the market?  Who’s going to use this?  Why?

 

And most importantly for the Project – I’m going to play the Bosses Advocate and I’m going to ask all these questions again from the business perspective.  I’m going to look at the following – the Corporate Mission and Goals, The Department/Divsion Mission and Goals, and then the Teams Mission and Goals and I’m going to map all of these subjects to them.  So I know as many of them as possible so that when I need to go for funds I already have the answers the boss is going to ask me.

Now – that’s what I call a PM Project Requirements Analysis.  Now I won’t say every PM should do this but I can tell you that if you do you will find that as you go through these same steps again for the real thing, you will find that it will make you a better PM.  Its basically gathering all the things you need for a project before hand or at least as many as you possibly can before you need them so that when you need them you’re not just ready you already have the answers.

Take the time to write this up on a simple two-three page document for every project you have.  Take and use this as a blue print to feed into your Communications Plan, you need to use it to build as many of your docs as possible.  Then as time goes by you need to go back to the doc and update it.  Whenever possible a personal document like this should be considered a living document that you update over and over. 

Like I said, I can’t say if you do this your life will be puppies and kitties and rainbows.  But.I can say that if you do this – it will make your life easier and your projects easier. 

Just my 2 cents.