Frank Patrick

PM Link: A Daily Project Execution Plan

The piece I’ve linked to today offers up a framework for focusing project communications on immediate tasks at hand. The author - Atul Gaur - thinks of it as a “daily execution plan”, but it bears very close resemblence to what I like to do on a weekly basis. The nature of the big single-project work domain that he works in probably makes daily worthwhile, but in the multi-project marketing agency and IT environments that I’m most familiar with, weekly seems appropriate.

Gaur lists a set of task data as the core of the immediate plan - things like current active tasks, tasks schedule to start, and issues or risks associated with them. What I like to do to gather these items is make use of an easy 1- or 2- week date range filter on incomplete tasks in MS Project to eliminate the distraction of the future stuff that’s going to change anyhow. In most cases, this ends up with a short list of current and up-coming tasks that are worth talking about.

The only additional further out tasks worth talking about are those that require an “alarm clock” to reserve or assign specific resources ahead of time. When the near term view includes a warning that this reservation might need to be made, it comes up at the appropriate time - far enough in advance to be useful, but hopefully close in enough to be confident about actually needing them when the [religiously updated] schedule say so.

In environments that accept the idea of buffered schedules, the status of the buffer - particularly whether it’s been consumed to the point that it might not protect the project promises - should be sufficient to account for the full health of the total project without overwhelming the team’s necessary focus on the immediate tasks at hand.

Since an active project is an evolving thing, the schedule needs to evolve as well. Focusing on the sequence of short-term needs makes the larger effort manageable.

[Previously shared with my Project Management “Circle” on Google Plus. Join it by putting me into one of your G+ circles and sharing a 1-to-1 post with me asking to be included.]

PM Link: Showing Your Team What Urgent Looks Like

(Note: Access to link requires free membership to ProjectConnections.)

The article shares a case study about a late project, featuring “key steps” for making the case for greater urgency in the system test phase of the project…

• Convene a frank discussion of the slips-to-date with the team, and the criticality of the approaching deadline.
• Create short-form test case list and schedule. 
• Appoint system test leader.
• Create white-board “war-room” type schedule display.
• Hold a test kickoff session.
• Hold daily hot-list meetings.

In my opinion, these are the kind of things that should have been happening well before system test was approaching. Some, like visual sharing of a war-room schedule and daily hot-lists, should be regular activities to keep the project on track so it doesn’t fall to end-of-project crunches on development or QA. Others should be considered as soon as the project starts feeling “yellow” instead of “green”.

In my old project management consulting days, I introduced the concept of a buffered schedule to a group of developers I was training on how to create an effective project culture. Someone in the back of the room commented “We’ve got buffers in our projects…

[pregnant pause]

…They’re called ‘system test.’”

[laughter ensues, then shaking of heads]

It’s up to project management to protect those at the end of the project from unacceptable encroachment on schedule and budget by over-run early-project tasks. That’s why the pay us the big bucks.

That said, it’s a good list of tactics and deserves a full read at Showing Your Team What Urgent Looks Like.

PM Link: Rework Will Happen!

Murphy’s Law has not yet been repealed.

As project managers, we know this is true. Otherwise, there would be less of a need for us. Yet a surprising number of project plans and schedules I’ve seen do not take into consideration the need to address the likely need for rework and revision, even though we all know it will probably appear.

The linked page, Rework Will Happen!, offers up one way of dealing with the risks of requiring rework - building iterations into the project network. To the extent that we can predict several such iterations of related tasks, this works fine. An old Focused Performance post of mine - Opening Up About Project Risk - offers another approach based in Critical Chain Project Management, utilizing range estimates for tasks, which can be applicable to rework that might occur within individual tasks. The latter approach can also be applied to the potential variation in number of iterations involved.

The best approach is to assure you use both approaches - build as complete a project network as is necessary to define the anticipated necessary work, and make use of a schedule that promises its completion taking intra-task and iteration variation into account as well.

PM Link: Deterministic Versus Probabilistic

Important discussion of why single point task estimates (and schedules/promises made with them) are not very useful.

[Deterministic Versus Probabilistic from Herding Cats]

Keeping Promises (On-Time Delivery)

From the article - Early is the New On-Time - by Tim Sanders:

Product launches and project implementations that run late or are re-scheduled at the first sign of complication.  Over the last decade, it’s culminated into a late-running nation of professionals that can’t be depended on to be on time.

But that’s coming to a screeching halt in the frugal “performance economy” - where excellence is the admission price to being gainfully employed or patronized by customers.  Being late now signals a lack of commitment or maturity that’s unacceptable when so many (more dependable) options are available.  So, I’ve made it a new policy to be a little early for everything.

Sanders provides a few prescriptions for fixing personal and enterprise timeliness. For projects, he talks about soft launches and scheduled launches. Not unlike the idea of buffered schedules. Being on time involves two aspects - making the promise, and delivering against it. Make a feasible promise that accounts for the variation that you know is going to happen whether you know or not the exact source of that variation, and delivery becomes a lot easier.

[link] - via ProjectSteps: Being on Time