How Much Detail is Enough?

by: stacey - February 22nd, 2012   Filed under: Project Management Add Comment

Project Managers all over the world struggle with this problem.  How much detail is enough in my project plan?

Most Project Managers error to the side of high-level tasks.  It’s easier to do at the beginning, everyone can agree on it, and it’s easy to get estimates on.

It’s also, unfortunately, what leads to problems.  Let’s say, for example, you have an implementation for a customer that calls for developing five pieces of functionality.  You put in a development task and appropriate testing tasks for each piece, then you put in a deployment task at the end.  That should be enough for the development piece, right?  You get your estimates from development- four tasks at four hours each, and one larger piece- it’s going to take a week.  Fine.  You move on.

Fast forward a month.  The one-week task took three weeks.  Testing has been a pain.  It’s gone back for corrections five times now.  Your deadline is completely shot, and no one can give you a well-defined date on when you’ll be done.

What went wrong?  Was the original estimate bad?

I would argue that the original estimating method was bad.

Modern software development isn’t like it was in the days of yore.  There are no monolithic programs (for the most part) anymore that it takes weeks and weeks to write the single thing, with no steps in between.  In reality, that one week task described above probably consists of a number of sub-tasks, like:

  • set up database tables
  • create object X
  • build method 1
  • build method 2
  • etc

Obviously, you do not want to micro-manage.  You also don’t want to overdo task list management.  I would argue, however, that any given task should span no more than one day in your plan.  If it does, then you need to break it down into sub-tasks.  Why do this?

1. When breaking the task down into sub-tasks, often your team member performing the task will become more accurate in their estimates

2. You can more effectively isolate trouble tasks to explain them and report on them.  How many times have you had this discussion:  You:  “Bob is running over on development.  He’s a week overdue on item X.”  Exec: “What part is he stuck on?”  You:  “Item X.”  Exec:  “What does that mean?  Can we get him help?  How much more does he have to go?”  You:  “Uhh…”

3.  You can actually get your team members help.  Staying with the developer example:  Is the developer overrunning on the database work?  Get a DBA to help them.  Are they stuck on a method in one of their objects?  Maybe another developer can complete another objects involved in the functionality to get you back on track.

4.  You can plan around day-to-day operations vastly easier.  If someone has a two-hour ops meeting on Thursday morning, and a conference call that evening, you can reliably say that they probably won’t complete their day-long task that day.  Push the timeline out one day.  Very simple.  A quick glance at your team members’ calendars tells you, and them, everything they need to know.

4.  Imagine how happy your team members will be when they figure out that they have a goal of one item per day.  Come in to work, do this by end of day.  No planning, no juggling, no balancing.  You complete your task and move to the next.  Simple.

5.  You create stopping points.  If team member X has to be pulled off the project for an operational thing for two days, you can simply insert that in the midst of a major task by dropping it between the subtasks.  Simple and elegant.

Getting the right amount of detail lets you follow up the right amount and estimate the right amount.  If a task consists of five day-long sub-tasks, then when three of them are complete, you’re somewhere between 60 and 80% complete.  Once your team members learn that they are suddenly not facing the “what percentage are you done?” question nearly as often, they’ll prefer your method as well.

Some team members aren’t going to like this method, because they do have to think through the details.  They will feel it is micromanagement.  It isn’t.  Being asked to state at the end of the day if you finished what you started out to do that day is not a big deal.  I recommend that you sit down with them and explain the benefits of this- they have one item to report to you, simple yes or no, at end of day each day.  Project status meetings become simple or non-existant.  They can get help when they need it.  Sell it however you must, but embrace this method.  Your project plans may get longer, but believe me, they’ll get more accurate as well.

Tags:

Adoption as a Step in Your Project

by: stacey - February 21st, 2012   Filed under: Product Management, Project Management Add Comment

There is a trend in software project management to assume that project success is simple:  If you come in on time, within budget, and meet the business owner’s list of requirements, then your project is a success.  It’s all about delivery.

Picture for a moment a restaurant focusing on the same thing:  they work on getting the food just right, delivered quickly, on time, and at a reasonable cost.  The steaks are always the right temperature, the tomatoes are picked at the right time, the cheese cakes are at the perfect consistency.  They work and work at it until they believe they have a perfect dining experience at the right price.  They open the doors.

Nobody shows up.  What did they forget?

The first thing you can point to is advertising and marketing.  Without some compelling effort to drive people to their product, it doesn’t matter if the product was perfect.  People don’t choose options that they don’t know about, nor do they choose options that do not provide a compelling reason to be better than their current choice.

How does this apply to software delivery?  Ask yourself this:  What if the users don’t understand its initial use, and use it wrong?  Will they use it after getting bad results?  What if they refuse to use it because it’s so different?  What if they don’t even know about it?  If the users don’t use it, or uses it in the wrong ways, then the project is not a success for the company.  If it didn’t succeed for the company, how can it be a success for you?

When you address success criteria for your software project, you can never forget two important details:  adoption and training.  Your project needs a plan to drive adoption.  It needs to start before you even get to training.  Your goal is that by the time you’re ready for training that the users can’t wait to use the product and are open and interested in the training process.

Adoption should not necessarily be driven from the PMO or from IT- this is not their areas of expertise.  Your company and business owner must help you here.  You need to engage them and help them understand that if adoption fails, the project is a waste of time.  Seek the right help within your organization.  Get Communications, HR, Marketing, whoever you need to involved to help drive adoption.  Your company sells to your clients- surely it can sell to its own staff?

Tags: ,

Managing the “C” Word

by: stacey - February 20th, 2012   Filed under: Management Add Comment

Consultants.  We’ve all either used them, been them, or both at one time or another.  Companies love them and hate them.  The pattern is usually something like this:

  1. The company needs more manpower or expertise in some area
  2. They have a brilliant idea:  Hire consultants!
  3. Consultants come in to help.  Since the company either hasn’t the manpower or expertise to do the project, they hand the consultants what they know and have, which isn’t much.
  4. Consultants start trying to do the job right (you hope).  They hold meetings, ask questions, gather requirements, start work…
  5. Company loses patience.  Needs product quickly, doesn’t want to spend money.
  6. Consultants give up on being allowed to do this right.  They hurry.  Requirements gathering sometimes suffers; writing documentation reduces drastically.
  7. Consultants hit company’s deadline (if you’re lucky).  Company asks consultants to turn over documentation and do a knowledge transfer to internal staff.  Company gives consultants a meeting (usually a couple of hours) to transfer everything the company’s needs to know about multi-month project to poor guy who may never have even heard of the consultant’s project.
  8. Consultant does so and leaves.  Company struggles to maintain what the consultant has done.  Company swears never to hire consultants again.
  9. Six months later, more consultants are engaged to redo what the last consultants did.

Sound familiar?  Some of this may sound extreme (or maybe not extreme enough, depending on your experience).  It happens all the time though.  Consultants are a double-edged sword.

A double-edged sword, though, in the right hands, is a very powerful weapon.  So how do you transition from an accident waiting to happen to a grand swordmaster?

The secret, as with most things in life, is practice and discipline.  Here’s tips for succeeding with Consultants:

Plan ahead:  You should have a plan in place as to what activities you believe the consultants need to do when they arrive and for the early period of the engagement at least.  You should go over this plan with the consultants beforehand and gain buy-in, adjust as needed, etc.  Frankly, if you don’t know what you’re going to do with them before they arrive, you shouldn’t be bringing them in yet.

Share Expectations:  First thing when you bring consultants in, give them a quantifiable, measurable explanation of what you need and what you expect of them.  Leave as few things vague as possible.  This will save time on both sides, as it should answer a lot of their questions, and if they weren’t going to ask questions, it will save you the pain of any incorrect assumptions they might have made.

Set the Standard:  Create a system of standards for the type of work the consultants will be doing- coding standards, database standards, data analysis standards, business analysis standards, etc.  You should already have these in place for your existing staff (and if not, you should really be correcting that).  Give these standards to the consultants when they come in-house as part of your expectations.  Just tell them up front:  “This is the way we do things here.  Consistency is important to us, as it helps us manage things long-term.  We appreciate any improvements you can suggest and will consider adding them to our standards, but we do expect you to follow the standards.”  Your people really will appreciate the consistency later, as it will help make the consultant’s work more familiar right away.

Review, Review, Review:  Conduct very regular reviews- code reviews, if they’re developers, document reviews, whatever is appropriate to the work at hand.  It may seem tedious, but a one hour review every week will help save you weeks of work later.  It will help keep the consultant on track with your expectations, assure they do stay within your standards, and the reviews will help you have a better grasp of what they’ve done later.

Feedback is everything:  Don’t review to grade.  Review to provide feedback.  Your consultants want to do the right work.  Regular checking in and providing constructive feedback will help them go in the right direction- and again, it will help you be more familiar with what they’ve done later, when you have to maintain it yourself.

Participation is encouraged:  Some people don’t like consultants to spend too much time chatting with the existing staff, coming to meetings, etc.  After all, they’re (usually) paid by the hour.  The more you can involve the consultants with your culture, though, and let them participate in informal sharing of information, the more they will learn to help them produce better products for you.  The information that they share in turn will help your staff better maintain their work after they’re gone as well.  There’s also countless little things that your staff can learn from the consultant- a quick infusion of new “tricks of the trade” is always good for the shop.

Do you have other useful tips for managing consultants?  Drop them in the comments!

Tags: