From developer to (part time) project manager -- hints?

Project management really is "Who does what by when", get that right and the rest is a whole lot easier.

Breaking tasks down into smaller units is a key part of project management.  It's generally called (in my experience) a work breakdown schedule or product breakdown schedule, try Googling both of those terms for guidance.  That coupled with your daily conference calls will help give visibility to progress.  If you can break things down to what can be realistically achieved in a day (or at least a small number of days) and get a daily report back you can get early visibility of any delays.  If someone report they are behind then just ask them how they're going to get back on track.  I would suggest a longer weekly call where you look at the progress for the week and discuss any issues and how they are going to be dealt with, from that produce a weekly 'Checkpoint' report and update your project plan.  Daily reporting/tracking would probably be too granular and may lead to over reaction, I've seen new project managers get het up over a critical path task being a few hours late one day (the person doing the task had just had a bad day) when that delay was easily made up the next.  Reporting weekly smooths out the bumps somewhat without leaving things so long that they can grow unmanageable.  Assuming you work a Monday to Friday week, Wednesday tends to be the best day for this weekly round up.  You avoid the OGIM and TGIF slumps and, if there is a problem that is going to require people to work the weekend you have time to organise it or get your people caught up by saying something like "Hey guys.  I'm sorry but if you can't get caught up by Friday we'll have to come in Saturday."  (I'm presuming that your people are salaried and so don't get overtime for Saturday working).

A few things that as a developer you may not have come accross but probably need to be aware of as a PM:

• Contingency.  Things will get delayed.  Fact of life.  Most of the time the delay can be made up quite quickly (like the example above where someone has a bad day one day so gets a bit behind but catches up the next day).  Somethings may not be so quick to make up so build some contingency into your plans and be prepared to swap things around, if possible.  If someone can't start the task you wanted them to start at a particular time because a preceding task hasn't been completed there's something else you can have them do, that was maybe originally scheduled for later, that keeps you moving forwards.  In my experience of IT projects by far the most likely cause of delays is external suppliers, in particular hardware deliveries and configuration.  If you're expecting someone to need a piece of hardware on, say, Friday then plan for it to be delivered and configured by Monday at the latest so giving yourself 4 days contingency for late delivery, DOA (Dead On Arrival) &c.
• Risk.  Basically anything that could go wrong whether it be a technical fault, something being delivered late, key people going sick, the company's financial director clearing out the company bank accounts and disappearing off to destination unknown with his PA (NB not a hypothetical example) or whatever.  List out what could go wrong, decide how likely it is and how big an impact it might have (just high, medium and low) and if something is highly likely and has a high impact (also medium/high and high/medium) decide how you will either prevent it and/or deal with it when it happens.  This is often called 'Containing the risk' and the plan a 'Containment Plan'.  It's not rocket science, an example might be "Risk:  Key hardware delivered late or DOA.  Containment:  When ordering hardware ensure delivery and configuration is scheduled to be completed at least 4 working days before needed."
• Requirements gathering.  This may already have been done for you.  If so, great, just check it's been done (signed off) and move on.  The biggest single reason for IT projects to fail is that the developers produced a product that wasn't what the users wanted because requirements were not gathered or were not correctly gathered.  Make sure that you know what the users want before you start coding.  Unfortunately many developers want to get started on the coding so skimp on this part.  Properly done requirements gathering often takes significantly longer than the coding.  However, properly done, it drastically cuts the development time as you only code what the user wants and don't have to go back and recode after the first code drop (or at least the recodding is minimised) as you don't have users saying "But we need it to...".  Well, not as much and if they do you can always refer them back to the requirements they gave you.  Requirements gathering also leads us on to...
• Testing.  I can actually hear the groans as I type this.  Developers tend to not like testing.  As a developer you've probably done unit testing (does this module work?) and maybe some Systems and Integration testing (does it still work when I put it witht he other modules).  As a PM you also need to think about User Acceptance Testing and more about Systems and Integration testing.  If you've done your requirements gathering correctly then this is actually a lot easier, you test against your requirements which give you your test cases.

 I hope that helps.  I've also moved from a techie role to a more PM/BA role in recent years so this is based on my experiences of doing that.

Stephen

--

Skype: stephenbooth_uk

DiSC: 6137

Experience is how you avoid failure, failure is what gives you experience.

If you haven’t already, listen to the Horstman’s Law of Project Management podcasts starting at: http://www.manager-tools.com/2009/01/horstmans-law-project-management-part-1.
 
I’m a full-time PM with a network administration background and learned through some trial and plenty of error.
 
I think you’ve got a good initial plan.  One thing that seems to be missing is having a clear definition of what needs to be done and why.  With inputs from your team and boss, this includes:

• What are the benefits and purpose of your project? 
• How do you measure the benefits?  
• How does this benefit help my company’s goals? 

 
Once you have a clear destination, the “who does what by when” is all the tasks it takes to get you there.  Every task should move you towards that destination you team defined. If not, then either the task is unnecessary/incorrect or your destination isn’t properly defined…probably the former.
 
What would I do in a situation like yours?  I would try to learn what I can to help me accomplish what I need to get done…that’s what you’re doing!  What I did that I would warn you away from is trying to “force” the use of new tools that weren’t appropriate.  For example, trying to track resource time to be able to get an earned value calculation on a 6 month project with all non-dedicated resources is an exercise in futility…and in hind-site, completely unnecessary.
 
What should I pay special attention to? #1 People: As High D & C as I am…it’s still about the people.  They’re the ones who have the knowledge and capability to get things done.  #2 Communication: Keeping everyone going in the same direction is all about talking to everyone (team, boss, stakeholders, etc.) and keeping them informed about how they’re are important to the overall plan and how the parts of the plan are important to them.
 
One on ones? At an effective manager conference, I asked Mark Horstman if one-on-ones are appropriate for PMs as well as managers.  He said absolutely. I do not have any direct ports; however, for my larger projects, I do have regular one-on-ones with team members who are have a significant portion of their time dedicated to my project.  (I guess my rule of thumb would be around 50%...but really case-by-case).  I think the feel is a little different than the MT one-on-ones (no boss stamp on my forehead), but I try to implement as close to the model as seems to make sense.
 
Good luck. I hope you enjoy PMing. I certainly have…there’s something about the thrill of many people working together to get big things accomplished!
 
-Jazz

Stephen, a great post. 

The last par tof the cast referenced by Jazz does say that Project Management IS management.  Do one on ones!  And Jazz, I do remember your question.

PM is also a great "trial to become a full-fledged manager" role, by the way.

While I agree 100% that the MT Trinity is the place to start I would recommend that you look into joining PMI and eventually get your PMP certification.  To be clear, I wouldn't be recommending this if you have any Project Management support within your organization but it sounds like you don't.

It is not that I advocate following everything laid out in the PMI methodology ( PMBOK ) but it gives you an idea of how to break down your projects to think about the different component areas ( risk, cost, quality etc... ) and make decisions how you are going to manage them.  While good software development methodology may have gotten you through as a programmer.  The fact is you will now have to be in charge of some of the stuff that happens before the coding begins ( what is oftern termed Project Definition ) and for that the PMBOK can be a useful guide to how to structure that thinking.

But.....if you have to make a choice between getting up to speed on PMI Principles and MT Principles....choose the MT Principles every time.