Tag Archives: Project Management

You Can’t Do it All – Enterprise Edition

We haven’t had a wonky Wednesday in a while, have we?

All right, so let’s tackle something that affects businesses big and small. In fact, it affects families, too. How many times have there been “too many things” to do or deal with in a week?

As it happens, I deal with project selection at work — and it makes me long for the family-based stuff. Why? The number of players involved in “what to do?” for a business is, more often than not, exponentially larger for a start. And if you think trying to get a five-year-old to accept you’re not buying everything in the toy store, just wait ’til you have to let an executive know they can’t get all of their 27 initiatives funded.

As probably comes as no surprise, the folks over at Harvard Business Review have thought about this a lot — and have come up with a list of seven ways in which your organization might be holding onto too many projects.

By definition, this really should be more useful to those of you dealing with project selection (and, frankly, killing off zombie projects) at work. But if you apply bits and pieces of this to the fam, I won’t tell.

Meetings and Purposes: Different Types of Meetings

If you’ve gone through the trouble of regularly creating a meeting agenda and gone a step further in crafting the agenda so it has an easily understood purpose and objectives, you’ve probably realized a central truth.

Not all meetings are created equal.

No, I don’t mean that some meetings are an abysmal waste of time and may, in fact, endanger your long-term health. Unfortunately, that may be true. I mean that you’ve probably realized that one meeting format doesn’t fit every need.

Especially as you are bombarded by people eager to innovate the dickens out of your workplace and “maximize value streams” or whatnot, you might be pressed to change how you’re doing business. That’s not bad, but as some improvement coaches can be hammers in search of nails, it’s important to remember:

One meeting size doesn’t fit all.

If you’re sincere about trying to make meetings effective –not just blocks of time people get together because “that’s what’s done”– and if you want to be honest about your meeting purpose, you’ll know that one meeting format does not work for every purpose… or even group of meeting attendees.

I can’t say I’ve got a magic formula for this, but especially with those of you who are tasked with being in charge of a project or a program, I think it’s useful to think of three different types of meetings. Those are:

  1. Status Meetings (Ongoing)
  2. Issue-Based Meetings (Sometimes Ad-Hoc)
  3. Lifecycle Meetings (Planned Status and Issue-Based Meetings with limited duration)

These three broad categories give you a framework for how to plan meetings — and to better understand what meetings you need to accomplish what objective. Let’s delve into each type:

1) Status Meetings
PMPs and other project managers are probably very familiar with one form of this type: the Weekly Project Status meeting. Most, if not all, of the project team meets to review the schedule, how we’re on track towards approaching milestones, and reviews project risks, issues, and action items.

“Daily Huddles” and “Daily Scrums” are also versions of status meetings. For many teams, these daily meetings have replaced the longer half-hour to hour weekly project meetings they previously held to monitor progress.

The frequency of the meeting usually indicates whether the discussion is more about tactical matters or strategic matters.

For example, if you’re finding your team is having problems with niggling impediments like software licenses or access, you may want to fold in some form of daily huddle to catch those issues quicker. Likewise, if you feel your team is getting a lot of “actions” done, but you don’t seem to be getting closer to your overall goals, you might need more status meetings where strategic goals can be discussed and further defined (note: depending on what level you’re at, this may depend on strategic conversations happening above your pay grade, but hey, at least you’ve identified the need!).

And be open to the fact that you might want and need both a daily and weekly status meeting. For example, the daily huddles could be purely about individual team members’ progress and impediments, while the weekly meeting could be status reporting with both the team and external stakeholders.

In all cases, be mindful of the audience and the purpose of the status meetings to ensure you’re not repeating the same message to the same audience. In fact, you want as much of your status and reporting to be accessible to most stakeholders (if possible) outside of meetings so that status meetings can be more about status questions and concerns, not simply information delivery.

2) Issue-based/Ad-hoc Meetings
These are one-time meetings or a series of meetings held to accomplish a specific objective.

You may recall that, during regular status meetings,  an issue might come up and someone, usually the facilitator, says, “Let’s talk about that offline.”

More often than not, that offline talk is going to be an ad-hoc meeting.

(Yes, that offline talk may be 2 people for 15 minutes, but even if it’s quite informal, it’s still a meeting to be held.)

Not all issue-based meetings need to be unplanned or reactive, however. If an executive has formulated a new initiative, your standard operating procedure may be to schedule a kickoff meeting or brainstorming session with the appropriate stakeholders.

You also may find that, due to uncovering some risk or issue during your regular status meetings, you need to have a series of meetings to address said risk or issue.

Two examples come to mind from software projects. In one case, we found out user acceptance testing wasn’t going as smoothly as we wanted and some major defects were found: defects bigger than we expected that jeopardized the release. We established a series of meetings with both business representatives and the developers to go through what workarounds could be created and what parts of the scope could be pulled back because it was determined we needed to launch “something.”

In another case, we were deep into development when we discovered a huge disconnect between the business and the IT teams on the requirements. We set up a daily meeting for a week to work through a host of previously unasked questions. The combination of all the stakeholders attending and a daily cadence meant a lot of the bull we dealt with previously fell away.

In both these cases, these issue-based meetings were in response to issues that came up with the project or program and needed to be addressed outside of the normal status meetings.

This it’s why it’s all the more important to understand the format and agenda for your status meetings. Sometimes, you can fit in the risk or issue at the end of the meeting after the main business is concluded (and attendees who are unaffected can leave). Regardless, it’s critical for any ad-hoc meeting to have an objective in mind, even if it’s simply to figure out which stakeholders are needed to discuss whatever risk or issue needs to be discussed.

3) Lifecycle Meetings
On one hand, these are simply variants of the first two categories: any lifecycle meeting is going to be either a status meeting or an issue-based meeting. However, I find it useful to think of them as a third category because of our natural tendency to want to “solve things once.”

Put another way, many of us want so much to establish a routine, we forget we could have a subroutine.

That’s where the Lifecycle meetings happen. For those of us that have done publishing, product launches, or software releases, there are certain meetings you have through the lifecycle of the said launch or release. There are checkpoints and reviews and tollgates that ideally occupy their own space and time separate from a status meeting. In addition, they’re not –or shouldn’t be– ad hoc. You know you’re going to have a meeting on that issue or topic and so you plan for it.

Here are some examples:

  • Before greenlighting the product launch, you need to have a meeting with marketing and legal to address any concerns they may have
  • Whenever you stand up a new technology system, you always need to walk through security and privacy impact assessments with your Information Security group
  • You hold a series of requirements gathering meetings with stakeholders before beginning a design phase
  • Before you conduct a software deployment, you go over the release plan for that weekend.
  • You conduct a series of user acceptance test sessions
  • Right before a product launch, you hold a series of training sessions for your customer support staff, so they can answer questions about the new product
  • Right after a product launch, you have a daily status meeting to check on how it’s doing and address any “early life support” issues
  • You have a series of lessons learned meetings with stakeholders after any project to help prepare the overall Lessons Learned document
  • And so on.

Remember, there’s often a temptation to stuff in some of these topics and work into existing meeting structures. And depending on the maturity of your meeting culture, this might work out fine.

But look at all those examples: you know you’ll need some of these meetings. Many of them are almost certainly going to involve people not in your regular status meetings. And there’s no reason to put off scheduling a meeting if it or a dependent outcome is in your project schedule.

And this is one of the other reasons I like to break out the “Lifecycle” meetings from both the status and issue-based meetings. Because people push back at planning for possible meetings the same way they often push back on risk planning (“there’s just too many variables!”), but they have a lot harder time arguing against things like planning to get input on requirements and such.

And once you have a lot of these lifecycle meetings identified and planned for, you might find a lot of the ad hoc meetings are simply unplanned versions of them… and in some cases, you’ll be able to plan for those meetings next time.

Because the life you save from abysmal, soul-sucking meetings may be your own.

Meetings: Agendas, Purposes, and Objectives

Okay, so building on last’s week’s post, let’s say you’ve decided that one key ingredient to successful meeting is an agenda. You’ve built your coalition of people who don’t want to waste time in meetings and perhaps pummeled dissenters with stale donuts until they capitulated. Maybe you even have a meeting facilitator –the one who pitches the donuts the strongest– to keep things on track.

So now what do you do to make the meeting agenda stick? Double down.

If people have agreed to an agenda and topics that (gasp) people know beforehand, you’ve already made your meetings more focused. Now you’re trying to make the meetings more effective… and decisive.

To do this, there’s two concepts to fold into your agenda: a meeting purpose and meeting objectives. These aren’t formal terms — at least not as formal as “risks” and “issues” are to project managers — but I’ve used them with several organizations and they seem to resonate.

The “purpose” is why you’re having the meeting. You can think of it as a meeting mission statement, but if “mission statement” makes you spend too much time figuring it out or you get too precious with the wording, just answer the question, “Why are we meeting?”

Examples:

  • The purpose of this meeting is to have all the critical stakeholders walk through the event “Run of Show.”
  • The purpose of this meeting is to discuss the IT system boundaries to use for the upcoming security audit.
  • The purpose of this meeting is to brainstorm about annual performance goals for our department

As you can see, the descriptions are not unlike a logline for a movie: they offer specificity without going into excruciating detail. Just from reading the meeting purpose, you should have a better idea of what you should expect to get out of the meeting — and even whether you should attend the meeting.

Meeting objectives pertain to the individual agenda topics. So, for example, for each topic, what do want to have happen in the meeting? Do you want to get a sign-off or do you simply want to elicit feedback? Do want to have a go/no-go decision or the date when you will have that decision? What things of consequence will happen in the meeting? Even the brainstorming meeting above can have an idea of where people hope to be with their brainstorming by the end of the meeting. What’s realistic?

Once you start setting objectives, you’re also setting expectations of what meetings can be. Meeting go from being something where you show up to something you prepare for and where things actually happen. It can be very exciting.

Bonus Round – Have a Feedback Loop
Does this whole process seem regimented? Perhaps overly so?

This is the danger of overly engineering your meeting. Your meeting facilitator needs to be sensitive to how effective the meeting is. In fact, all the meeting attendees should be prepared to change the meeting format if the meeting purpose isn’t being met.

It all goes back to the meeting purpose. Let the meeting format fit the meeting purpose (form follows function and all that). I’ve seen a huge rise in using lean concepts and scrum-type meetings in part because that meeting format effectively serves the purpose of those meetings, whether it’s for frequent daily updates or quickly identifying impediments to getting work done.

And that points back to purpose. Sometimes we pesky humans need more than 10 minutes to mull over an idea collectively. Not every meeting needs to be stage-managed down to the micro-second as long as it is valuable. There is value to more open-ended meetings. I’ve been in many a joint application development (JAD) session that was pretty free-wheeling. Of course, ultimately, we had to set some constraints. Attendees did not have unlimited time to give and we had goals for what we wanted to accomplish by the end of said JAD sessions.

Another thing to consider is that any given meeting’s purpose may change over time due to the needs of the organization and also, we need to be honest, the temperaments of the meeting attendees.

I had a weekly meeting where I was a stakeholder that essentially served as a support group for middle managers. We compared notes on decisions made by executives and how they would affect our multi-department project. When I became the meeting facilitator, I updated it into more of a rumor control meeting where we would make sure we were all on the same page about what the issues were and what next steps needed to be taken. After that, the meeting still served its purpose of rumor control, but evolved into a more formal discussion of risks added to risk register. This also necessitated opening up the meeting to more stakeholders, but since the “culture” of the meeting was established, they adapted to the meeting format rather than value being lost from the meeting (strong meeting facilitation and buy-in on the meeting’s purpose are crucial to preserve useful meetings as attendees change).

In another instance, we had the obligatory weekly staff meeting which often had status updates going around the room. With new leadership came a new approach and a daily stand-up meeting to talk about status on work-in-progress and help with impediments. Our weekly meeting remained, but it became more about lengthier discussion and internal presentations. When leadership changed, both meetings remained, but there was a new look at how to make the daily stand-ups even more valuable.

This goes to a central idea of Lean being that “there’s always room for improvement.” Or if you want to be more snarky, making sure that meetings are not where productivity goes to die.

Next time, I’ll talk about different types of meetings and how they relate back to purpose. As you’ve probably gleaned, more often than not, no one meeting type will do.

When it’s good to have an agenda: meetings.

I’m going to post on project management topics in what I’ll call a new wonky Wednesday tradition.

Since we’re now deep into the New Year (well, for the Federal government anyway), I thought I’d delve into the bane of so many people’s existence: meetings.

To paraphrase a common sentiment about writing, I don’t like meetings, but I love having met. Why? Because within any enterprise, there’s decisions to be made and issues to be hashed out and discussed. Sure, you can do one-on-one conversations at someone’s desk or fortuitously bump into the right people in the hallway sometime during the workday. But seriously: a good meeting is a place where decisions can be made and next steps are defined. A good recurring meeting blocks out a time and place to assess the status of a project and make sure stuff gets dealt with.

If this rosy picture of meetings bears no resemblance to meetings you’re beset with, I understand. Believe me, I too have suffered hours and hours of tedium, labeled as “meetings.” I have endured time-sucking blather that the organizers purported would be useful. Moreover, the people who foist these life-draining events on us seem to exist in every organization in every corner of the globe.

But you can fight back.

First and foremost: wherever you can, whenever you can, make sure any meeting you have to attend has an agenda.

Yeah, this is different from all the agendas people might come to meetings with like “make sure my group isn’t blamed for anything” or “how can I fill the hour with my talking and without getting assigned any tasks?” These people will descend upon meetings regardless of your best efforts.

Your agenda, should you choose to accept it, is to do whatever you can to make sure the meeting has an agenda: by which I mean at least a listing of topics or explanation about what you are to discuss.

Once you take the step of having this meeting agenda, you will have established a foothold from which to launch additional improvements to your meetings. For example, when you insist on an agenda, you can:

  • Push for a regular time before the meeting the agenda gets sent out. (This helps reinforce the idea that meetings are planned for.)
  • Push for supporting materials to be attached to the meeting invite or otherwise circulated beforehand. (This helps push the idea of preparing for meetings.)
  • Establish a template for those materials, especially if they’ll be displayed during the meeting, so they focus on decision points. (This helps get people on the same page and communicate in mutually agreed ways.)
  • Assign action items during the meeting. (This helps keep people accountable and on track).
  • Capture meeting minutes. (This not only aids documenting action items, but also helps reduce people needed in meetings.)
  • Send the previous meeting’s minutes along with the meeting agenda. (This helps keep people up-to-date)
  • Establish a time during the meeting you can go over meeting minutes. (This helps establish a cadence of getting stuff done).

While you are fighting this good fight, you’re sure to get resistance. Even the best people are busy and sometimes honestly don’t have time to prepare for meetings because of many other meetings and fires that spring up. And planning isn’t as exciting as firefighting, so you’ll also get pushback from those who get a thrill out of fighting fires. I mean, coming in and saving the day is so, so much more exciting than status meetings. Getting that thrill is, well, thrilling.

I’ll talk more about dealing with the firefighters and thrill-seekers in more depth in a later post. For now, bear in mind that you can’t completely ignore people who give you pushback on regular meetings and regularly formatted meetings. To make and maintain your gains in creating meaningful meetings, you need to be mindful of “what’s in it for them?”

  • Are the meetings a place where decisions can be made?
  • Are the meetings a place to discuss issues and risks openly?
  • Are the meetings a place to clarify matters?

In short, a meeting needs to bring value to the whomever is attending over and above what sending an email, having a one-on-one conversation, or just reading meeting minutes would provide.

For this reason, you need to be open with the structure of your meeting. This whole post is about adding an agenda to a meeting, but there are plenty of meetings that won’t fit some of the traditional improvements I described above. Perhaps you have some of these short, stand-up meetings meant to be 5-15 minutes versus the more traditional 30-60 minute meetings that inhabit offices.

In this case, your agenda is making sure this short meeting has the proper structure. That structure fulfills the same purpose as a traditional agenda: it helps define the flow of the meeting.

Having that structure is your first key in making the meeting valuable and gaining allies to keep the gains you’ve made.

But if you want to make sure you can make gains, a great first step is simply to ensure your meetings have an agenda.

Bonus Round – The Meeting Facilitator
Creating agendas for meetings is all well and good, but as with so many attempts to aid efficiency and sanity, the improvement depends on people.

So if you want to keep on course to have more meaningful meetings, you want to make sure someone is wearing the hat of meeting facilitator. This need not be the team lead or manager. In fact, some meetings benefit from that leader not being the timekeeper. They get to think strategically while the meeting facilitator is tactical. By tactical I mean things like:

  • Noting where the conversation is off topic and suggesting a follow-up meeting or one-on-one to discuss to handle the issue
  • Making note of action items: who took the action, what it is, and hopefully, when it will be done.
  • Making note of the overall time left in the meeting — which may mean some topics get skipped

Just like a meeting structure should be organic and open to improvement, what, where, and how forceful a meeting facilitator may change over time.

But one of the key things a facilitator can maintain is that your meetings have an agenda.

Schedule Management: Exceptions to the 0-50-100 Method

I realized I hadn’t been posting much about producing and project management this year, so here’s a series of short posts going over some of the concepts I cover in the project management training I do.

Previously, I has talked about a method for managing your schedule: the 0-50-100 method of reporting and tracking completion percentage.

Again, for context, this is all about how to report completion percentage for a (presumably baselined) schedule. In other words, first you do your work breakdown and have all your tasks. Next, you use your personal experience, historical information, and knowledgeable people to figure out how long this is all going to take. In go all the durations for all the tasks. Painfully, you get sign-off and agreement that the tasks will take that long — and all of a sudden you’re off and running with the project.

Are you 0n track? How do you stay on track? If you’re using a tool like Microsoft Project, your tasks can be marked by percent complete. My recommendation is to use three –and only three– percentages:

  • 0% (Not Started)
  • 50% (In-Progress, whether it’s just started or almost complete)
  • 100% (Unequivocally complete)

I still believe this is one of the best ways to manage a schedule — especially for those of you using Microsoft Project. No project is ever so unique that it can’t benefit from any management (despite what some stakeholders may insist)… and the 0-50-100 method allows you to focus on pragmatically solving roadblocks rather than obsessing about reporting minutiae.

However, even though projects aren’t so insanely unique to preclude managing them, they also don’t all fit into one mold. The 0-50-100 method may not work for all tasks, so I wanted to share two other major ways to calculate ‘percent complete.’ Depending on your given project, you might use them a lot, a little, or not at all. In most cases when I use them, I use them in conjunction with 0-50-100 (in other words, my ‘percent complete’ reporting methods are task specific with 0-50-100 as the default).

Percent Complete by Unit
This method is where you mark the percent complete based on a number of units. For example, if you’re in the testing phase of a software development project and your testers need to complete 100 test scripts, that’s 100 units. If they’ve completed 15 test scripts of the 100, you’re 15% done. You have your overall duration of the task within which you estimated all 100 scripts will be completed, but for reporting purposes, you’re being more granular than 0-50-100.

The key variable to keep as unvaried as possible is the nature of your given units. As much as possible, you want your apples to correspond to apples, or at least similarly sized oranges (assuming size is the logical criterion for comparison). You don’t want to compare apples to watermelons in one task. If you do have a watermelon unit amidst a bunch of apple units, that’s where you’ll want to break down your schedule further. Have a separate watermelon task if you can (which will probably be tracked as 0-10-100) and you can have the remaining apples be tracked by unit.

Remember, there are no hard and fast rules. It’s all about the level of granularity by which you want to manage the project… balanced with how much bandwidth you have to manage the project.

I’ve often tracked the workflow of change requests or articles by unit — knowing full well that some requests are more complicated than others or some articles are longer than others. However, collectively, tracking their completion by unit averages out and is easier to manage.

For example, back when I did project management for a publishing company, it was not uncommon to have tasks pertaining to proofreaders, copy editors, and so on. Tracking tasks per page was a natural fit for this kind of work. However, between dense scientific articles and annual reports replete with flashy graphics, any given pages were not going to take the same amount of time.

This goes back to your work in estimating the duration of your tasks. You always want to ask yourself and your team how long a given task will take, as it may vary from project to project. Maybe you can save time proofreading the pages for this particular repot because it’s an annual report with lots of graphics. But then, so you need to increase the per-page duration of the design and layout tasks? And bear in mind, after you’ve done a few annual reports or scientific journals, you should get some good per-page estimates or other estimated durations.

Likewise, for articles in the magazine realm, all articles are not created equal. Maybe I have a separate “per unit” task for feature articles and one for columns. OR, I might go ahead and have a task for each column, knowing that different columnists have different foibles and are best managed by the 0-50-100 method (“Okay, Frank: have you even started yet?”).

Remember, you should be dividing up the tasks to best be able to monitor and manage those pesky humans responsible for the tasks. Reporting on completion should be the same way.

Level of Effort (i.e. Percent Complete by Time Elapsed)
For purely schedule management, this may not come up as much, but this can be very important in overall project management as it makes it easier to tie the schedule to cost.

(Please note, several project managers who could never perceive a world where you didn’t tie schedule to cost to do nice, crunchy Estimated Time to Completion and Actual Cost just had their heads explode. That’s okay. Manager head explosions are a known risk.)

Because it’s good for overall project management, I like this method for tasks in two main instances: for executive reporting and where cost control is paramount.

As an overlay or executive view of the overall schedule, looking at the percent complete by time elapsed is a good way to judge progress from the “50,000 foot view.” In my experience, executives are most concerned about a project’s end date and what the project’s objective is more so than minutiae anyway. If you combine “percent complete by time elapsed” with the cost assigned to the task or overyou can get a good idea of what start-ups and contractors love to term “burn rate” (how fast you’re using up your funding).

For the financial managers among you, this can give you a diagnostic or monitoring tool. If a team has spent 60% of their budget, but only 30% of your schedule has elapsed, perhaps they ran into some complications they’re not reporting. Likewise, a team that has spent 20% of their budget, but 50% of their scheduled tasks are done, did they overestimate? Are they not reporting all their costs? When you are operating at the program or portfolio level, this can be very useful, because while you’re still concerned about making your schedule, you’re looking at a bigger picture (presumably, you have project managers for each project, working in the weeds).

For example, instead of knowing every task for requirements, design, build, testing, and deployment of several software projects, you, as a program manager, might know the start and end dates for those projects and have the percentage of budget assigned to each phase (e.g. 20% of budget for requirements, 40% for build, etc.). Now you can use the level-of-effort cross-matched with your financial reporting to see if any of your projects are under-burning or over-burning. In this way, you’re still using the project schedule as a way to learn if you’re going to make your date, but you have the cost tied to the schedule in such a way that it can be an early-warning tool of projects going off track. And at the program and portfolio level, you often need to deal with funding and supply issues more than an in-the-trenches project manager.

That cuts to the heart of this method. For me, tying the percent complete to the time elapsed works best at a phase or output level vs. a task level — because I’ll tie it to the cost and “burn rate.” Checking percentage this way at too low a level gets back into the silliness I described last time, where people quibble about 37% vs. 39%. Absent of whether you’ve spent 37% or 39% of your money and absent any other attempt at objective criteria, who cares? Nevertheless, this type of view is probably more useful to many managers and executives, so it’s worth figuring out how and where you’ll use it.

Overall, for project managers, I’d suggest looking into using the 0-50-100 percent complete method for your tasks except where doing percent complete by unit will allow for better management. Then, look at the overall project or program, and see how to apply percent complete by schedule elapsed tied to cost in order to give good reporting for the program and portfolio level.

Schedule Management: The 0-50-100 Method for Tasks

I realized I haven’t been posting much about producing and project management this year, so I’ve decided to do a series of short posts for a few weeks going over some of the concepts I cover in the project management training I do.

If you want to spend more time managing your schedule and less time staring at it, at one time or another, you’re going to hear about the 0-50-100 method for managing tasks.

In my case, I was first introduced to it by a program manager where we were working on an integrated project plan that ran over 1,700 lines. There was no way we’d spend every status meeting figuring out the exact percentage of each task – nor what we needed to monitor to make sure we’re on track.

This is where the program manager let me in on a time-saving, sanity-saving trick, especially when using a schedule management tool like Microsoft Project.

I should probably back up a bit and clarify that this schedule management tactic is for when you have created your project schedule. Hopefully, you have broken down the work into logical tasks — and you have used your acumen, other people’s acumen, and historical information to give those tasks reasonable durations.

Now, to make sure your project schedule is not merely decorative shelfware, you’re using the schedule as a living document, getting updates as to whether tasks are complete or not — and by what percentage.

When you think about asking for the percent complete of a given task, that’s where this method makes so much sense. That’s because most, if not all, tasks can be expressed as one of three states:

  • 0% – The task has not been started.
  • 50% – The task is in process. Maybe it started yesterday. Maybe it’s about to be finished tomorrow. It doesn’t matter. For reporting purposes, any “in-process” task is always 50%
  • 100% – The task has been completed (and the people who need to confirm it’s completed have said it’s completed).

There are exceptions, which I can talk about in another post, but consider this: how valuable is knowing completion percentage anyway?

Do you really need to spend a single precious meeting minute on whether something is 37% or 42%?

No.

Anyone who is obsessing about that either falsely believes those abstract numbers will help OR is trying to evade the real question you or any other project manager wants to know:

Can we make our schedule?

It’s rare that I’ve been at an organization where schedule is not, ultimately, king. The 0-50-100 method allows you to zero in on risks and impacts to your schedule.

Here’s how those three simple statuses above help you do that:

0%, the Task hasn’t started.
Is it past the start date?

No? Good. Is there any reason to expect why this task won’t start on time? If the start date is within two weeks, does the task owner know they’re expected to start soon?

Yes, it is past the start date? Okay, how do we get started? What date should it start now — and how does that affect the project being completed on time? (aka, the critical path).

50%, the Task is in-progress
Cool. Did it start on time or did it start late?

If it started late, is there anything we’re doing to make sure it still completes on time? Are those efforts working? Do you need any help to make sure it gets completed on time? At all?

If it started on time, is it going to be completed when we scheduled? How confident are you? Are there any risks popping up that would stop you? Do you need any help to make sure it gets completed?

100%, the Task has been completed
Wonderful. Does everyone agree (who needs to agree) that task has been completed? Are the subsequent tasks starting on time? Does anything need to be communicated?

Is this task like any other tasks still being worked in this project? Were there any risks or lessons learned we should communicate right now about how this task went down?

###

In other words, as a project manager, you’re using the 0-50-100 method to focus on solutions and support. The more time you spend debating and delineating exactly what the status of a task is during project status meetings, the less time you have to try and make sure things are on track or get back on track.

In other words, it saves time — and it focuses what management really wants to know: will the project be completed on time?

Eschewing “To-Do” and Using a Done List

I have been dealing with a number of deadlines for the past few weeks from Team J to my own writing… and of course, with my project management hat on, I’m always looking for ways to manage the lists and lists and lists of to-dos more effectively.

I’m sure I’m not the only project manager who gets calm by organizing or revising a to-do list. For all there is to do, it does feel like bringing some order to the chaos. But at the same time, there’s usually a lot to do. Frankly, looking at my lists in Workflowy, I have no idea when I’m going to get to everything. Some days, it really, really helps to total up all the different things you’ve done.

(For parents, this goes double.)

So when I read L.V. Anderson’s article a couple weeks ago about trying to have a “Done List,” I have to say it resonated.

Of course, I only had a chance to post this now. But then again, now I get to put this post on my “Done List.”

 

The Differences between a Policy, Process, Procedure, and Work Instruction

After last month’s deep dive into the realm of writing, I suppose it’s only fair that I touch on the fine art of producing and project management.

Simply put, just as a “risk” and an “issue” are different in the land of project management, so too are documents like a Policy, a Process, a Procedure, and a Work Instruction.

On a very basic level, you could think of them as increasingly detailed versions of the same picture. So:

Policy –> Process –> Procedure –> Work Instruction

However, beyond a simple “high altitude to low altitude” example, there are also considerations as to who your audience is and what you want to accomplish. You don’t need all four levels of documentation.

Explaining where and when you should go that deep can be tricky, which was why I was happy to see someone take a stab at it. Please consult this brief but handy guide to the difference between all four.

I like it enough, that I can kind of forgive them using “it’s” instead of correctly using “its.” Kind of, but not quite.

But before I digress too much about proofreading documentation, I wanted to get back to the importance of defining what level of documentation you need.

I spent a couple years creating and revising business processes for a couple different clients. For one of them, I had the luck of working with an “ITIL Jedi Master” which, though apt, was not his official title.

It was developing documentation for this client where I truly came to appreciate the different goals and different audiences of the four types of documentation.

You always need some form of policy — and luckily, in most organizations, someone has done that. (I say “luckily” — you’ll find many people in the trenches resent the existing policy and their de facto procedures are designed to undercut said policy). You might even have process. The tricky part often comes with procedure and work instruction. Because the differences between process, procedure, and work instruction can seem abstract, you will often find one document trying to fulfill the objective of all three document types — and failing spectacularly. Not only that, the people who need to sign off on the process don’t care about the work instruction level — and can often get confused by it. The cutoff between the procedure and the work instruction level can be very tricky. That’s why I like the example above.

Here’s an example: one of the areas we did a lot of documentation and service improvements was an IT Operations department. We had IT Operations staff who needed the work instruction level of detail for many tasks because they were both entry-level positions with a reasonable rate of turnover and because if very specific instructions were not followed, mayhem could ensue. In some cases, by re-doing a process flow, we were able to identify the process steps that were taking a long time. Re-doing and getting management buy-in on the revised processes gave us the authority we needed to examine what was working and what wasn’t working on the procedure and work instruction level. We could target which work instructions to revise and replace for the biggest bang for our buck in terms of service levels. It wasn’t easy, but by separating the documentation levels — both who the audience was and who needed to sign off on them, we were able to have more far reaching improvements to IT services than we would have otherwise.

You will always find people in an organization that dislike dealing with documentation. Usually, this resistance has one of two causes:

  1. They are the keeper of tribal knowledge related to this procedure or work instruction and feel it is tied to their job security
  2. They have never seen documentation help them

Note that these two causes are not mutually exclusive. Also, consider how much #2 can be because the documentation tries to be a policy, process, procedure, work instruction.

You need to validate policy and get buy-in on process, especially if it’s a revision to the process, but once you have that, you may be surprised how much can be turned around by tactical improvements at the work instruction level. Once word gets around about how you’re helping eliminate headaches, the proponents of tribal knowledge may remain, but have fewer allies.

All right, that’s probably wonky enough for this time of year. Why don’t you go to that new space movie?