How do you handle project status (red/yellow/green) with 'squishy' tasks?
By 'squishy' I mean... The edges of the tasks blur into each other, or they otherwise can get mashed around a little. Instead of rubber or glass balls they're like those stress-relieving balls you squeeze in one hand.
Background/further explanation:
I've been mentally resisting a couple things in the project management casts, and I finally figured out how to word my objections, sort of. Specifically, the one where Mark says you don't succeed at a project if you fail on the first few deadlines, and no, you don't make up time later because you learned some things on the current one. My specific area is software development, but I'm sure there are others where this applies too.
Here's how a typical project week can go for me:
I have these tasks. Tasks 3 through 6 are related and are dependent - 4 needs 3 done, 5 needs 4 done, etc. Then there's 12-14, where 13 depends on 12, but there's no relationship to tasks 3-6. (Say, a different module of the application I'm working on.) 3-6 are this week and part of next week, and in three weeks I'll be starting on task 12.
I start working on task 3, that's what I'm scheduled to work on next. Halfway through 3, I get stuck. After a while it occurs to me 'you know, if I had about half of 6 done this would be easy', so I tell my project manager that I'm going to work on 6 for a bit so I can make 3 go better. (Apparently, I didn't understand either 3 or 6 well enough to tell they overlapped this way. THAT is typical of task definition on software projects. Or maybe, because I'm dealing with linear project management tools instead of mindmapped...ahem, anyway. :) ) PM's ok with it, and anyway I'll just end up redoing 3 when I get to 6 anyway if I don't do this prelim work; waste of effort, so good, this will save us a bit of rework and not make me go over.
Next day, PM sends me an email. 'Hey, task 14 will take 1 day and the customer really wants it. Can you finish that today and give it to them for testing tomorrow?' I reply with 'Uh...no. Because while I can probably do 14 without 12 and 13, if I have to, that 1-day estimate is predicated on 12 and 13 being done; 14 really needs their stuff to work correctly.' 'I thought you said it would take 1 day.' 'Yes. If I've done 12 and 13 first.' 'Well, they really want it, so get it done as quickly as possible.'
So I switch to task 14, contemplating what I'd have to do from 12 and 13 without actually taking the time to do 12 and 13, since between them they'll take a week and that's not fast enough. I figure something out and 2 days later I have something that will work for 14 and can be expanded for 12 and 13 too.
Then comes Friday, and I'm asked: Why aren't you done on tasks 3 and 4? They were supposed to be done this week.
Is my project red? I have, in this week I was supposed to work on 3 and 4, made progress on 3, 6, 12, 13, and completed 14 (though I may have to go back and fix it up some once I can do 12 and 13).
This happens to me a lot. I just consider the task rearrangement part of my reality - that happens - so I don't worry about it too much. I'm usually quite confident I'll still hit my ultimate deadline for the whole project. And I usually *do* hit my ultimate deadline.
So... Is the project red?
Hard/squishy mismatch
It sounds to me like you have two different issues here.
First, the project plan or requirements are not worked through sufficiently to understand the relationships between different parts of the project (your 3-6 and 12-14). Essentially, nobody has said "Hey, these things kinda go together, so they should be worked on together." Like you said, "squishy" tasks.
Second, your schedule is getting rearranged without a matching rearrangement in your end-of-week status list. If the PM says to work on 14, then your status on 14 is what you should be asked about on Friday. (Did the customer agree with the original plan? Shouldn't the PM push back to defend it?)
I live in the same kind of world, where project management and planning are very vague concepts. Tasks get pulled to the top of my list regularly, regardless of their actual importance.
You have a situation where "hard" status checks are being used with "squishy" project planning. Perhaps the best answer to the status check is that tasks 3 and 4 are red (they are not completed) because of reasons X, Y, and Z (specifically including the PM rearranging your schedule).
Red status is not fatal -- it's just a fact. The PM should work with you to adjust the plan to get back on track.
flexiblefine
Houston, Texas, USA
DiSC: 1476
The squishiness of the tasks
The squishiness of the tasks doesn't bother me much - it's just reality. They change. There's always some question that doesn't get asked that leads to more information that changes things. New rules, regulations, laws, policies, or whatever impacts this or that. And I may not have been clear - 3-6 (for instance) would be listed in an MS Project as subtasks of 'feature 1 work', and 12-14 are subtasks of 'feature 3 work'. So they're known to be related; it's just that if you lay them out, the 'obvious' order is 3, 4, 5, 6. It's only when you dig into 3 that you realize you should gather data for 6 up here, because it's more sensible on this screen, or whatever. You just never quite know. (If you spend a lot of up-front design time working out an exact, 'correct' project schedule, you waste a LOT of time - because when the requirements change, you have to redo the design, and then the tasks are all out of whack too, if you got down to knowing precisely in each task what you're going to do.)
I like the 'hard status checks are being used with squishy tasks' as a mental construct for framing it.
As an example of how requirements change, a coworker of mine once had a date field he was putting on a form; it's a due date. So, of course, he adds validation to verify they submit a date.
When he demoed the form to the customers, they said 'oh, we need to be able to type in 'next week' or 'ASAP' and have it display that text - not just a date'. Who would have thought to ask about that? Not me...even after I heard that story I never really thought to ask 'do you actually mean to have a date here, when you say this is a date?'
I think we're on the same page
Yes, we do live in the same kind of situation. Where "I need these products added to the database ASAP" often comes with no actual data. No names, descriptions, prices, photos, etc. Yeah, I can get right on that. :)
flexiblefine
Houston, Texas, USA
DiSC: 1476