Frank Patrick

RSS

Posts tagged with "project management"

On Performer Over-Utilization

There are still too many project organizations that put emphasis on keeping everyone busy, due to the erroneous assumption that “an idle resource is a major waste.”

Someone on one of the discussion groups I participate in recently suggested one way to get managers to think about the error of these ways…

Ask “If your people are 90% utilized, how long would it take (without overtime) to recover from missing a day of work, or of running into Murphy’s Law to the tune of a day? How about 95%? 99%?” With a little bit of thought, the dangers to speed and throughput quickly become evident.

Innovation Is About Arguing, Not Brainstorming.

2. SAY “NO, BECAUSE” It’s widely evangelized that successful brainstorms rely on acceptance of all ideas and judgment of none. Many refer to the cardinal rule of improv saying “Yes, AND”—for building on others’ ideas. As a former actor, I’m a major proponent of “Yes AND.”

But I’m also a fan of “no, BECAUSE.” No is a critical part of our process, but if you’re going to say no, you better be able to say why. Backing up an argument is integral in any deliberative discourse. And that “because” should be grounded in real people other than ourselves.

“No, because…” without the “ethnographic research” talked about in the article can be based on one of three “becauses”…

  1. Because I don’t see how the idea solves the problem. This is likely a question of clarity, that might require a couple more ideas to address. A collection of ideas (aka tactics) strung together forms…wait for it…a strategy (in either the general or specific sense).
     
  2. Because I foresee some negative side-effects associated with the idea. Opening these up and addressing them will allow the team to fully flesh out a complete solution - a complete strategy - that gets the benefits of the idea without the unwanted side-effects.
     
  3. Because while it sounds worthwhile, we’ll never be able to make it happen because “we don’t have…”, “we don’t know…”, or some other obstacle. This is where breaking the idea down into a set of dependent tasks and sub-tasks come in. (AKA the planning phase of project management laying out the steps to implement the tactics and accomplish the strategy.)

On Reporting Project Task Progress

Percent complete is meaningless.

Aug 1

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.]

I’m a project manager, baby, and I’ve got a task for you…

PM Link: The Client's Responsibility for Project Success

I’ve been known to suggest that the toughest resources to manage in a project are your boss and the project’s client. This link offers some thoughts about what it takes to maximize the latter’s contribution.

Bottom line…if you’re a project client, try to help the project team help you accomplish what you’re looking for from the project.

PM Link: On Priorities

Reblogged from idealgentleman:

A gentleman always knows what matters. He always knows what’s most important.

People talk about “priorities” and “priority lists”; they talk about “top ten priorities” and something being “a high priority”.

The truth is, you can only ever have one priority. Something is either your priority, or…[go read the rest]

Why do so many professionals say they are project managing, when what they are actually doing is fire fighting?

- Colin Bentley, 1997

Multitasking Mug
 - Reblogged from dannahsaur:

MULTITASKING? Naaaah. 

Multitasking Mug

 - Reblogged from dannahsaur:

MULTITASKING? Naaaah. 

PM Link: Value of Project Managers

A study reported in The Economist suggests that a case could be made for value in game software revenues that’s more attributable to project managers (producers in the game world) than designers.

…some 30% of differences in revenue between games could be attributed to the producer and the designer alone; and that the lion’s share of this variation was due to the producer. The boring project manager, in other words, meant more to the success or failure of the project than did the flashy designer. Moreover, the effect seemed to persist even as the individuals moved on to other projects, so more than one game could benefit from the same competent producer.

This makes sense in a business that thrives on time-to-market. Get the game into the stores sooner, and you get more time to sell it before competition arrives. And who keeps the design/development projects moving? Project Managers.

…having a thoughtful producer on board, able to curb (or indulge) the designer’s wilder impulses and make sure that deadlines are met. Rather than being interchangeable, suggests the research, managers, and their talents, matter a great deal to the success or failure of their projects.

Of course a creative game design attracts customers. Of course quality development assures desirable game play. But a few more weeks, or months, in the market, an effective producer project manager provides more opportunity for earlier revenues. If revenues are linked to product launches, then time-to-market, shepherded by your PM, is key to achieving your goals. [linkage via Scott Berkun]

In other environments - interactive agencies, for instance - in addition to the contribution to the top line from timely delivery, project managers are also instrumental in predicting costs, which, in the hands of smart management, informs pricing of services and assures company profitability.

PM Links: Multi-project Management and Organizational Effectiveness

Links to last month’s 4-part series…

Part 1 - Organizations are multi-project systems

Part 2 - Organizational effectiveness is resource effectiveness

Part 3 - Managing the present and the future

Part 4 - It’s what you finish; not how much you start

And I will strike down upon thee with great vengeance and furious anger those who would attempt to poison and destroy My PROJECTS!

And you will know My name is the PM when I lay My vengeance upon thee!

-

(reblogged from emadness)

PM Post: Relay Race, Interrupted

Quite a while ago, back in my independent consulting days, a discussion list I participated in carried a thread about how to engrain and assure appropriate behaviors in management of a project organization. Around the same time, the following had come into my inbox from a different source, and for some reason I thought of that discussion…

There’s a story about an MIT student who spent an entire summer going to the Harvard football field every day wearing a black and white striped shirt, walking up and down the field for ten or fifteen minutes throwing birdseed, blowing a whistle, and then walking off the field. At the end of the summer, it came time for the first Harvard home football game, the referee walked onto the field and blew the whistle, and the game had to be delayed for a half hour to wait for the birds to get off of the field.

A clear demonstration of the power of consistently walking the “squawk.”

There’s also a story from personal experience with a client that shows how deviating from the promised behaviors can get management into trouble. It happened in an implementation of Critical Chain-based multi-project management at a telecom equipment firm building systems of integrated hardware and software. Critical Chain training was given to management first (since they had to have the ability to “walk the talk” from the get-go), and then to members of the project teams as the projects were revisited for completeness of plan and alignment with the multi-project processes.

One of the key concepts demonstrated by games and simulations in the training is the idea of the “project as relay race,” as opposed to the usually date-driven metaphor of a train. The team picked up on this idea with a vengeance — so much so that they went out to the local sporting goods store and bought a set of relay race batons, which were painted brightly, and attached to a rope so that they could be hung on a doorknob or on the entrance to a cubicle.

Read More

Jul 8

Productivity Link: Save Our Inboxes! Adopt the Email Charter!

We’re drowning in email. And the many hours we spend on it are generating ever more work for our friends and colleagues. We can reverse this spiral only by mutual agreement. Hence this Charter…

Jul 6

PM Post: A Relay Race, not a Train Schedule

Most projects are managed by carefully watching the calendar, comparing where we are today against some baseline schedule. That schedule typically consists of a series of start and due dates for consecutive tasks, with due dates of predecessors matching start dates of successors. Like a train schedule, if a task arrives at its completion on or before its due date, that portion of the project is considered to be “on track.” Successor resources plan other work and their availability around those dates. If the predecessor is finished early, the successor resource may not be available to pick up the handoff. Even if the resource is available, there is commonly little or no urgency for the successor to start (or to focus on it exclusively), since we’re “ahead of schedule,” and that resource will typically tend to other priorities.

The problem with this common practice is that while it is important for trains to arrive at and depart from their stations (their milestones) at appointed times, project value is more often tied to the absolute speed from beginning to end. The sooner the entire project is completed; the sooner project benefits can be accrued. A more appropriate metaphor to guide projects is a relay race, in which resources are encouraged to pick up the input handoff as soon as it is available, “run with it” in a full, focused, sustainable level of effort, and hand off the output as soon as it is complete.

Read More