• Glen defining “done” in an agile context.
• From Hal, Misunderstanding Project Planning as Anticipation, and some commentary providing some clarification on “continuous re-planning” from Jack.
• Eliminating the 90 Percent Done Game, a StickyMinds.com article from Johanna (Not done is not done.) Also, Codependent Schedule Games from the same source.
• From Jack Dahlgren, a piece on the difference between rules and principles associated with project management.
• Stephen Seay asks “What is your project management process?” and points to the TenStep Project Management Process, a methodology for managing work as a project.

We, at my job, are considering other tools, trying to get better at what we do, so when I read this thread, I was impressed. This discusses the very issues that we are struggling with.

“It’s not the tools, it’s the people.” Where doesn’t that apply in life?

———

Here’s this week’s situation:

We’re a startup company of 7 programmers and I’m the closest thing we have to a PM. Problem is none of the famous, fancy project management tools, and I’ve tried them all, make it easy to really track work. They all seem to do about 40% of what I need, but abandon me for the rest, forcing me to use 4 different products, none of which have a clue about each other.

I’ve decided i have 5 questions that I ask, but that no one tool will answer for me:

- How confident should I be in my schedule next week
- Are my programmers being utilized at near 100%
- Does everyone know what’s supposed to happen next week
- Can everyone easily update estimates, and flag new issues, so I can see them
- Can I make/track task assignments without annoying everyone

Right now I have the following tools:

- A bug tracker
- An excel spreadsheet
- Basecamp (37 signals)
- Email
- A bottle of Jim beam

I have two questions for discussion:

1. How do these top questions match everyone elses?
2. What is your list of top questions, and which tools are you happiest with using to help you answer them?

- Hating all of my tools

_______________________________________________

So, this guy walks into a music store and says to the manager “I want the most expensive electric guitar you have and I want the best amplifier and a full set of pedals. Oh, and make sure all the cables are gold plated and certified.” The manager looks the guy up and down and says “Wow! That’s quite a rig you want. What kind of music do you play?” The guy looks back at him and says “I don’t know how to play a guitar. I figured with all this expensive gear, that it would do it all for me.”

To be honest, it sounds like your looking to buy a guitar here…

Tool sets should augment a process which has already been shown to work not reinforce ones that don’t. I suspect that the reason you have a bottle of Jim Beam in hand is that you are trying to use tools to automate the wrong thing.

So ask yourself, “Do I really believe that my processes for communicating with the team, handling workloads, tracking issues and adjusting estimates are correct?” If not, no amount of throwing tools at it will help.

My suggestion? Go back to recipe cards or post-it notes on a very visible wall. Talk with everyone on the team daily to touch base and cover the issues and empower the programmers to walk up to the wall and re-arrange things. Do a post-mortem on every estimate over the last while and figure out what worked and what didn’t. Learn what adjustments to apply to what estimates. In short, work out what works for you and *then* look for some tools to help automate aspects of it (or not, personally I like the ‘wall of work’ just fine for some situations).

Perhaps you hate your tools because you bought an electric guitar and you really wanted a classical one instead.
(analogies stretched with little or no mercy today ;-) )

_______________________________________________

Before answering this question, I’d like people to think about the following things:

The Great Pyramids
St. Paul’s Cathedral in London
The Apollo space program that landed Neil Armstrong on the moon

These are all massive, multi-year (or decade) projects that have had an enormous lasting impression on generations of people. For each of these, they didn’t have much more than a pad of paper, pencil and and abacus (ok–for Apollo, they used slide rules).

You have hundreds of thousands of times the tools and compute power that each of these teams needed to get the job done, yet they succeeded. Maybe, this isn’t a tool problem?

I’ve decided i have 5 questions that I ask, but that no one tool will answer for me:

- How confident should I be in my schedule next week

No tool available is going to be able to answer this question. This is based on a number of things, but ultimately, it comes down to being able to understand what issues your team is facing, whether they understand how to address those issues, and how confident they are in their estimates. While it would be theoretically possible to put together a tool which you would put estimates and track how people did against those estimates, and thus generate a weighting of those estimates over time, this is time consuming, data intensive, and probably not reasonable unless you have a phenomenally large budget–which you apparently don’t.

This is a “gut check” question. And you will get better at this over time with your technology, team, management, etc. Also, you have to make sure that you are asking the right set of questions to make sure that the team fully understands the issues in front of them, and thus are accounting for them in their estimates. Experience is the way that you typically find this out. The reality is that as a startup with a (likely) new technology base and (likely) new people, you have a learning curve, and you aren’t going to be very confident of your schedule for a while.

How do you know which questions to ask? By running into obstacles. Then asking questions to figure out how to avoid that obstacle.

Oh, and even if *you* are confident, you boss–if they are smart and experienced–aren’t going to trust your confidence. You have to show them. Your team has to show you, etc.

- Are my programmers being utilized at near 100%

Unlikely. And you probably don’t want them to be. Are you willing to not have staff meetings, phone calls, bathrooms, email, IM, or other tools? Are your people? Is this an office, or a chain-gang?

Normally you can only utilize your staff about 75-85% of the time. Life intrudes the rest of the time.

- Does everyone know what’s supposed to happen next week

I don’t know. Why don’t you ask them?

- Can everyone easily update estimates, and flag new issues, so I can see them

Probably not. Sometimes a tool isn’t the best vehicle for this. Often, the issues are best expressed verbally or visually.

- Can I make/track task assignments without annoying everyone

No. No matter what you do the answer is no. If you come up with something that looks like the solution, the answer is still no.

A better question to ask is “How do I make/track assignments so that I cause the least amount of disruption/confusion/duplication of effort in the team?”.

Right now I have the following tools:

- A bug tracker
- An excel spreadsheet
- Basecamp (37 signals)
- Email
- A bottle of Jim beam

These tools all can work. Fancy-schmancy project tracking software can’t really do any better of a job than these tools can do–if you use them appropriately.

By far, the most useful tool that you have as a PM is a pad of paper, your feet, your 5 senses, and that bottle of Jim Beam. Remember–don’t drink alone: invite a team member and talk about the project. Relax, kick back and probe the details. Think of hard questions, and ask them in ways that don’t make it sound like you don’t trust your team.

I have two questions for discussion:

1. How do these top questions match everyone elses?

Not bad. But really it looks like you are asking “What software do I need to get in order to run my project automatically?” The answer is: “Ain’t no such tool.”

2. What is your list of top questions, and which tools are you happiest with using to help you answer them?

Tools aren’t the answer. Tools are like conceptual models: All models are wrong, some models are useful. Software is the same way. Many software tools can be helpful and necessary, but they won’t solve all the worlds ills.

You have tools for :
bug and issue tracking (Bug tracker)
Activity and task tracking (Basecamp)
Issue/dependency/risk tracking and reporting (Excel)
Low fidelity communication (e-mail)
High fidelity communication (walking and talking, and Jim Beam :))

These really are all the basic tools that you need. Everything else is icing on the cake, and the cost may not be worth the expense of adding more overhead.

-mark

_______________________________________________

>
> Before answering this question, I’d like people to think about the following
> things:
>
> The Great Pyramids
> St. Paul’s Cathedral in London
> The Apollo space program that landed Neil Armstrong on the moon
>
> These are all massive, multi-year (or decade) projects that have had an
> enormous lasting impression on generations of people. For each of these,
> they didn’t have much more than a pad of paper, pencil and and abacus
> (ok–for Apollo, they used slide rules).
>

This is not a fair comparison. They took years and years to complete
and cost the earth and moon. If a project can take 25 years and many
millions of dollars, then you’ve already increased the chance of
success. Aggressive scheduling and under budgeting are too common
unfortunately.

Having said that, I agree with everyone else. For your circumstance a
tool is not the answer. You say you have 7 programmers and you want to
know if everyone knows what is supposed to happen next week. Why not
just ask them? Is everything going to schedule? Ask them.

Have an arrangement where you have a 30 minute discussion on Monday
about what you are going to do this week. Write it on the whiteboard
or a chart (or use a post-it). Then take 5 minutes every morning and
see how things are going, can anyone take additional tasks, is anyone
overworked, should we readjust the schedule, are we stuck etc. Take 30
minutes on Friday evening to review the week and see how you can
improve next week.

Total time taken: 80 minutes a week.

You’ll get all the information that you need. Not just you, but the whole team.

_______________________________________________

These tools are .. well just tools -like a garden hoe .They need to put to work by some intellect behind them .

As a manager or the closest thing to a manager ,you need to be able to make things happen ,track , allocate and estimate with or without tools .

Have you set up a process first up for each macro task in your project ?

Are you sure the process works ?

Does the process have the consensus of every member in your team ? Dissenters need to be spotted and convinced .

Is a forum established for openly airing views / opinions ? (These will help in getting the consensus regarding almost anything and also encourage healthy disagreement )

Are there more exceptions that the rule when the process is in place ? If so your process is defunct and needs to be tailored / replaced with some innovative
thinking .

No tool gives you confidence on the schedule -it is only your people who do!!

Are you tracking tasks for some personal benefit or for the organizations’s vision ? I donot understand why somebody would get annoyed when assignments are
being tracked .

I get the feeling you are jumping more into the easier and more objective part of Project Management which is collating data and bandying about
hi-fi tools rather than concentrating on getting the job done and developing the team .

People give you results !! Tools only consildate them !!

regards
anand

_______________________________________________

I’d argue the implication that increasing time and budget improves
the chance of success. There are an enormous number of examples where
large scale projects failed horribly because the team lost focus,
changed goals, lost interest, or just plain lost control. While
having an unlimited budget allows for some flexibility, it doesn’t
ensure success. The Department of Defense has a huge number of well-
funded failures. So do Microsoft, IBM, AT&T, Apple, and others.

Besides, the point was that tools don’t help make a success–
dedicated, focused people do. i believe that the comparison is valid,
though I would agree that the scales don’t match up.

-mark

_______________________________________________

> Your feet are critical. Walk around. Talk to your team, to the customer, to
> the janitor if need be. The way to take the pulse of the project is to touch
> it. Management by Walking Around (yes, that’s a formal term) needs to
> balance being intrusive/nosy with being supportive, but it’s a balance well
> worth finding. You need to be honest and responsive and open for it to
> work. “Hey, Robin, how’s it going?” can elicit either “Fine” or “Not bad,
> but I’ve got this weird bug I’m wrestling with‚Ķ.” If you’re just hearing
> “fine,” either they’re blowing you off because you’re not being open and
> honest or you’re talking to my 11-year-old daughter when I ask her about
> school.

I think this is one of the reasons we’ve seen such a rise in the
different Agile methodologies… think of Scrum specifically. In your
daily standups, you have to say where you are, what you’ve done since
the last one, and what’s blocking you. By putting people on the spot,
you’ve effectively shamed them into *not* giving you the “11-year-old
daughter answer”.

On the tools front, I’ve been deploying dotProject for numerous
companies since 2003 or so and the first thing that I do is ask for an
explanation of their current PM practices. I’ve learned the hard way
that if they don’t know what they’re doing and then get a tool that
doesn’t solve it all for them in their specific impossible to guess
way, it’s not their fault. It’s *obviously* the fault of the
inanimate object that doesn’t know anything about their operations.

_______________________________________________

” The Department of Defense has a huge number of well-
funded failures. So do Microsoft, IBM, AT&T, Apple, and others.”

Hey now, how did we end up in that mix? LOL

All kidding aside, the larger the company, the more likely to have some
real whammies for projects.

Everyone who has posted thus far is right on.

Even on a large project, with 40+ people actually working on
deliverables, I have to “walk” around (I walk virtually). I create a
project atmosphere that encourages candor, and people say things that
clue me into issues they don’t recognize as noteworthy. My pad of
paper, my observation skills, and my willingness to be the brunt of
others’ frustrations just so I can get at the truth are the tools I
can’t live without.

To answer your questions directly:
- How confident should I be in my schedule next week:
If you aren’t 100% sure about your schedule over the next 7 days for 7
programmers then you’re in trouble.

- Are my programmers being utilized at near 100%:
They’d better be. If you don’t have enough work, then now is a good
time for them to start working on a standard delivery process for your
company. Having a documented delivery process will help you bring in
new programmers, PMs, and others more smoothly.

- Does everyone know what’s supposed to happen next week:
If they don’t, you might include, “tell people what they should be
working on next week,” to the list of PM responsibilities. ;)

- Can everyone easily update estimates, and flag new issues, so I can
see them:
In our organization, we report all our time and vacation in one place.
And we have to report time end of every week and proposed vacations at
the beginning of the year. This helps us to predict resource
availability for projects. We use a database, however your company
could use a whiteboard.
We flag our issues in our project stand ups or in conversation. As PM,
I track them both in my pad of paper and in a project database.

- Can I make/track task assignments without annoying everyone:
If this is a question, perhaps the programmers haven’t yet realized the
importance of the PM role. When I was on a small team of all
programmers, we shared the PM responsibility from project to project.
It’s amazing how quickly we learned the role was critical to our
success.

I suggest: hire a person who is a PM soon. Someone with the skill set,
the passion for the role, and the guts to take on a team of start-up
programmers. The things that frustrate or elude you will simply be “all
in a day’s work” for them.

If you wait until things are falling apart, you’ll have to bring in
consultants to rescue your failing projects. The big companies can
absorb the cost of project failure/rescue fairly easily, but start-ups
are not typically that financially resilient.

_______________________________________________

Ditto on the tools vs people argument. While I’ve never been a PM, I
have been in a leadership position. I was there long enough to know I
don’t have the talent for it. I had much more enthusiasm for using the
tools to gather the data and analyse the schedule than I had for
actually managing the team. That’s why I’m a individual contributor
again.

You really need a full time project manager who actually likes the job
of managing people.

Also, for those teams who pass around the PM role from project to
project…. stop that! I garantee there is at least one person (if not
more) who does not have the talent for being a PM and is hurting the
project he is managing. Do everyone a favor and get a real project
manager.

:)

_______________________________________________

I wouldn’t say that I’m putting folks on the spot or shaming them into giving answers.

That doesn’t work with my daughter, either.

Rather, I’m structuring opportunities for them to tell me what’s going on and let me know how comfortable they are with progress. My goal is to do this as unobtrusively as possible, both to minimize time on “status stuff” and to let them drive the agenda, such as it is.

I did “exit interviews” with my old team as I prepped two of them to take over my role. I learned that they weren’t really aware of the extent to which I was doing what I describe here. This speaks either to my incompetence or my ability to stay on top of problems without them feeling they were being “watched.” I’d prefer to believe the latter, of course.

I hadn’t thought of agility in the context of developers not telling PMs when they were stuck on something. On the other hand, one clear goal of agile methods is to encourage dev teams to share with each other — with peers — their needs, dependencies, and problems. And if they’re sharing with each other, there’s no reason the PM can’t eavesdrop….

_______________________________________________

Nice. Where can I get me one of that kind of guitar?

For our PM, if you are unhappy with your available tools . . . what aren’t they
helping you do? What would you like to have happen that isn’t happening with
these tools? What aren’t they helping you to do?

Maybe what you want is doable. Maybe not. Until you know what you want any
hammer will do, and any hammer you grab is unlikely to solve your problem - you
know, the one you haven’t named yet.

_______________________________________________

I disagree with some of the things that Mark said, but perhaps it’s just due to a difference in how I interpreted the original questions or the author’s intent. Everyone else on the list has also covered the “you don’t need tools” angle, so here’s my pitch to look for a better tool set.

It’s really important to know how confident you can be in your schedule, and you must learn from your past experience. If you are using any tool that lets you enter estimates for tasks, it should also let you enter the actual time spent on a task, and it should be trivial to find out how the actual matches up to estimates. If you’re not tracking this, then you’re not giving devs feedback on their estimates, and there’s no way they can hope to improve them in the future. You can also use the simple system where you add up the estimated work units done in one period and use that to gauge how much work you can do in the next period. Assuming your team is consistent with estimates, this should tell you what you need to know for a small team and a short schedule.

Are your resources being fully utilized? I do agree that that’s not specifically a tools question, it’s a “talk to each developer often” question when you have such a small team. But time-tracking tools can help you find inefficiencies and help you understand where time is really being spent. And being able to track things like time spent fixing defects can help you find ways to improve your processes and be more efficient.

Does everyone know what’s supposed to happen next week? Obviously, you should ask them. But for the sake of a more productive discussion (or just for fun), let’s rephrase that question: does everyone on the team know how to find out what the next step in the plan is? What the next work item is? Face-to-face communication (or direct virtual human-to-human communication) is critical for the success of a project, but you should rely on tools to capture the specs, test plans, etc. about those conversations. If you’ve done the work to make a plan, your tools should make it easy for everyone to see and act on that plan.

Can everyone easily update estimates and flag issues? Depending on what you mean, Mark’s obviously right: you have to work when there are issues. But a team is better off if the person working on a task can update it in your workflow tool with the most current information instead of sending an email to you so you can update your Excel schedule.

As for assigning work, a tool that helps you see what an engineer’s workload is when trying to assign tasks can certainly be helpful. I think that Mark is saying that you can’t toss work over a wall and expect it to get done properly, but everyone needs some kind of system for tracking the work they have to do, and when that system helps the PM see the schedule as a whole and the work queue for each individual, there can be benefits.

I do disagree with Mark’s statement that “Fancy-schmancy project tracking software can’t really do any better of a job than these tools can do–if you use them appropriately.” A tool that effectively combines more than one other tool you’re using can be a tremendous advantage if it improves communication with your team, makes important information more visible, removes duplicated effort, and helps your organization scale.

For a team of any size, you need to find the processes and communication mechanisms that work and then try to find the tools that best support them. You can start small with what you’re using now, but I don’t think you should give up the search for a set of tools that fit your needs better. You will hit a wall with one of them soon enough (my money is on the Excel spreadsheet).

For the record, I hate the tools we’re using, and I still dream of finding a better one someday. We’ve gone from note cards and Excel to crappy open-source collaboration software, then to a browser-based tool on a local server, and finally to a hosted service as our team has grown, and each one has brought welcome improvements to our productivity. But I’m still looking for the next one that will suck less. :)

_______________________________________________

So, here’s the intrinsic problem with PM tools - manual, automated, local,
distributed, ad hoc, theoretically grounded and imaginary. It’s the same problem
project have, actually. They serve a bunch of masters.

Developers want to be left alone to invent, can’t predict all that accurately,
and aren’t all that bothered by being unable to predict. Project sponsors want
the results - they’re indifferent to the joys of invention. For stuff that looks
like production tasks (in the generic sense of “producing stuff”) they don’t get
why it’s so variable. They can be very bothered by the inability to predict
accurately - legitimately, cost and business impact bothered. I’ve dealt with a
dozen companies or more which were at risk of going out of business simply
because of the costs of unpredictable software delivery. Users care that they
will still be able to do their jobs, and are often highly biased toward
deferring implementing something, while developers usually want to get on to the
next thing, and the folks running the business want their payoff as soon as they
can get it. And so on.

Project tools are the same way. It turns out that the guy who’s brain is full of
this piece of code of the moment isn’t all that interested in when the whole
thing will be done. Projecting that forward distracts him vs. helping him. Tools
that help with the projecting and the tracking, well, help the folks juggling
the huge symphony keep some kind of idea what the whole mess looks like. Good to
know.

The guy who wants to know what his next thing is to do (on a card or similar)
has needs different from the guy who wants to know when it will all be done.

There are even different “communities” with something as immediate as the code.
When my little brain is full of the problem of the moment, I have not many
cycles to spare for making navigation hints. Worse, I’m in no position to write
navigation hints - it’s all in my brain. I’m not dumb enough right then. When I
come along later having forgotten everything about what I did, the code itself
may be incomprehensible to me. I need navigation hints. Even, just me, one guy,
the developer, is (are?, am?) really in two different communities when dealing
with the same code. Of course for the guy funding this, the code is a
re-taskable asset. It does a thing, and he’s wanting it to do that thing spread
out over space, time and features.

So, three views of a piece of code:
- What I just invented. (Cool!)
- This thing to understand. (Huh?)
- This re-taskable asset. ($weet.)

Same goes for every other thing going on on a project, and, indeed, there are
more than three views of each. This *is* the problem with projects.

> For the record . . . We’ve gone from note cards and Excel to
> crappy open-source collaboration software, then to a browser-based tool
> on a local server, and finally to a hosted service as our team has
> grown, and each one has brought welcome improvements to our
> productivity. But I’m still looking for the next one that will suck
> less. :)

I like tools where the traceability between the different views is handled in
the automation. I’m extra happy when the planning, status and so on comes right
off the mechanisms we use for doing the work - right off the actual work flow.
Tying all that stuff together by hand is tedious, error prone, and subject to
gaming. Why not have the computer do it?

So, I’m enthusiastic about some developments tying some of this stuff together:
Trac, the development server bundle CD from ThoughtWorks, and even some of
Microsoft’s Sharepoint development server stuff.

Back before we had all the big electronic hammers I used a different trick that
still helps - define the workflows for each perspective like developers, project
management, and so on, so that they automatically tie out. Why on earth would
you have a developer thinking in terms of one slicing of “tasks” and project
management in another? Holy impedance-mismatch, Ohm-boy.

For example, if you are making code, it traces to a feature, slice or change
request - the non-developer’s view of the inventory we’re producing. If you are
making code, it’s “done” when “done” means passes some explicit gating, gating
that *is* the task exit criteria in any task view of the same work. So,
development workflow, feature-defect-change request workflow, and tasks on a
tasking view all tie out.

But, that’s just me. I’m too dumb to keep track of three different views of the
same project, let alone more.

_______________________________________________

It seems there are two types of tools: those that make your job
easier by automating manual and repetitive things, and those that do
your job for you by automating decision and analysis. The former
category make it easier to do menial tasks (e.g. keeping the list of
everything left to be done, so it isn’t in your head, adding up the
work estimates and correlating that against vacation time) so you can
concentrate on the decision and analysis your job requires (are we
going to ship on time?). The latter category are usually somewhere
between useless and reckless — there are tools to help you come to
an answer, but I’ve never seen one that can accurately give you one
on its own.

So the question is: what kind of problem are you trying to solve
with these tools?

_______________________________________________

We now pause while I fire my inner editor. My apologies for speaking
hastily.

The “between useless and reckless” is unfair. There are plenty of
tools to assist in analysis and in making decisions. My concern is
when we get to the point having the tools *make* the decisions for
you, especially when you don’t understand their methods. If you
understand statistical analysis and know how to use a good monte
carlo simulation tool (I’ve been pretty happy with Crystal Ball) then
the tools can help you get a handle on bit problems that are likely
beyond the capacity of your brain to deal with in a short time.

If you *don’t* understand these tools and just let them make
decisions for you you’ll probably get the wrong answer. The same is
true pretty much all the way down the complexity curve, and I’ve seen
too many people defer to the machine when they’re getting a GIGO answer.

-faisal

On Jun 28, 2007, at 12:37 PM, Faisal N Jawdat wrote:

> It seems there are two types of tools: those that make your job
> easier by automating manual and repetitive things, and those that do
> your job for you by automating decision and analysis. The former
> category make it easier to do menial tasks (e.g. keeping the list of
> everything left to be done, so it isn’t in your head, adding up the
> work estimates and correlating that against vacation time) so you can
> concentrate on the decision and analysis your job requires (are we
> going to ship on time?). The latter category are usually somewhere
> between useless and reckless — there are tools to help you come to
> an answer, but I’ve never seen one that can accurately give you one
> on its own.
>
> So the question is: what kind of problem are you trying to solve
> with these tools?
>

_______________________________________________

I think Faisal’s point is deservedly strongly worded. Computers are great at automating manual, repetitive project work. If you can find a toolset that wrings out the effort there with a good ui, you’ve handled most of your pain. This allows you to focus on the higher-thinking aspects of project management.

Can tools help in higher-thinking too? As a BI vendor, I should hope so. But let’s get real - it’s pretty tough and you need to carefully check out what the machine is doing. And in the absence of a gizmo to think for you, you need to rely on the human basics (as everyone has emphasized). Jim Beam looks like a good start.

We lean heavily on FogBugz for much of our project management. Personally, I’m looking forward to the upcoming release, which claims to throw a little Monte Carlo into the mix. But I’ll verify before I trust.

_______________________________________________

Maybe you are looking for different tools because of lack of confidence as the PM or poor use of the current tool set. I’ve seen cyclical OO development projects with the best relational and project management/collaboration tool sets fail as often as similar sized “classic” structured code projects tracked on a wall. It simply comes down to good management - the tools make it more efficient.

Tools allow you to construct very elaborate project plans and schedules, track progress, aid collaboration, etc. How you use the tools is as important as the capabilities of the tools. Everybody always wants “better” tools - get the electric or battery powered over the manual. Sometimes manual is good enough and occasionally better than the high tech version. I’ve never found a tool that does everything I want for any extended period of time or in every circumstance. A tool set used on one project may need upgrading for the following - that’s life.

However, getting back to the original problem…

If you have difficulty tracking a whole 7 programmer’s progress, you should be asking questions of yourself not the tools, i.e. “Am I the right person for the job and are my PM skills adequate? and Do I need PM/management training?”.

Seven programmers is about the average size of a team or cell managed by a team leader who is expected to have his/her finger on the pulse.

If you have doubts about the schedule going forward, then this is probably because of one the major mistakes made in most projects - poor estimation and your doubt will be caused by seeing slippage, high bug numbers, tons of rework, significant numbers of test failures (both unit and regression), etc.

My experience is that very few organisations have any form of estimation database - yet another tool. If they do, they struggle to keep it updated either during the project or at the post mortem. All activities should be tracked against original estimate (and who did the estimate) and where slippage or early complete outside of the allowed tolerance has occurred, the key factors should be recorded, categorised and analysed. It’s funny how you can quickly see who the problems are, both in estimation and performance. Danger, danger Will Robinson - chances are that the people that did the original estimation have been overly optimistic, are generally the long-term respected gurus that are the same ones used for estimation on every project and your project will likely overrun by the same proportion as previous. But I digress‚Ķ

With 7 programmers you should be very confident of the schedule next week apart from one or more becoming sick, having a personal problem, blowing a fuse or other force majeure.

I don’t understand the question: “Are my programmers being utilized at near 100%?”. Why not have a look at the schedule! Mind you, if you ask each one of them personally, they will tell you they flat-out. If they are the lazy guru type, i.e. they get the job done in half the allocated time but waste the rest, they will appear to be tracking to schedule but real utilisation is only 50%. This is a performance management issue. If the schedule isn’t showing 100% utilisation, clearly they will not be fully utilised. I am making one assumption here, that critical bugs are worked into the schedule. Otherwise it is really easy to lose control with staff working off-schedule on bugs with no expected time-line.

As for everybody knowing what is going on next week, you can meet with them and tell them and/or send out an email with a list of who is doing what and who is working on critical path tasks. The information is obtained by applying a report filter in a tracking tool or looking at your post-it notes on the wall.

You really don’t want to have staff updating estimates directly into the schedule - they can enter % complete and that’s all. If they wade in and change estimates the whole project could blow-up as the key focus areas/critical path will change from one moment to the next. You need to be in control and apply effort where it is needed to keep the project on track, not the staff shifting end dates. Remember, % complete entries from staff are only estimates. When you start to see slippage, find out why, then fix the root cause.

Isn’t it the PM’s role to “make/track task assignments” whether or not it is “annoying everyone”?

Seth’s Blog: Letting off steam

Josh points us to: Clientcopia : Coping with stupid clients

So a client calls me on a Friday - 4PM.

CLIENT: I’m about to talk to the pharma client, I need a computer graphics budget for an interactive CD-ROM.

ME: Great, email me the project details, how many screens, client deadlines, etc.

CLIENT: Well, can’t you just give me a ballpark figure?

ME: A ballpark figure? But, I don’t know any of specs, nor any of the client info. Please send me what you have, I’ll look over it this weekend and I’ll have something for you first thing Monday morning.

CLIENT: Well, we need to send them something today, by 4:30PM. Can’t you just estimate it?

ME: Okay, $100,000.

CLIENT: $100,000! Why is it that much?

Is the issue that he’s throwing around statistical concepts in an
effort to snow people (”If you can’t dazzle them with
brilliance…”), or that he’s just plain making up fake data?

Either way, it sounds like you need to call him on it, but your
method will need to vary based on which problem you have.

If it’s the latter case, is this outright deceit, or just wishful
thinking? I’d ask him to back things up, and then show causation.
If it’s wishful thinking you’ll need management to understand that
they shouldn’t trust his numbers without verifying. If it’s deceit
you have a bigger (if more obvious) problem.

If it’s just a fire-hose of statistical nonsense, treat it in the
same way as you’d treat a fire-hose of any other types of buzzwords:
figure out who in the organization actually knows something about
statistical methods and get them involved. If the answer is “no one”
and it now falls to you (or you’re bored), read (warning, contains
colorful language), then peruse some of the books listed at the end.

-faisal

_______________________________________________
PM Clinic - www.scottberkun.com/forums/pmclinic/