Tag: Methodologies

Demystifying Lean Six Sigma

Written by Mike Morton on May 29, 2012. Posted in Articles. 7 Comments on Demystifying Lean Six Sigma

In today’s competitive global market, all companies are looking to make improvements that drive bottom line results. Many of these organizations are turning to process improvement methodologies such as Lean Six Sigma. While this is a great starting point, your first question may be, “What exactly is Lean Six Sigma and how is it different from Six Sigma or Lean?” Your next question may be, “If my company is not in manufacturing, would Lean Six Sigma even be applicable for my organization?” In this article, we will answer these questions by providing an overview of the fundamental framework of this methodology. We will also draw on our SEI experience and take a look at how companies are using Lean Six Sigma as well as some of the common pitfalls.

What is Lean Six Sigma?

The first point that is important to understand is that Lean, Six Sigma and Lean Six Sigma are three different methodologies. All center on the fundamental concept of doing things better, faster and cheaper, but from different perspectives.

Lean Six Sigma is a natural evolution of the quality and process improvement disciplines that originated in the 1950s to improve manufacturing. It began with a focus on improving quality in order to decrease the cost of producing defective material. This evolved into applying similar principles to improve process efficiency on the factory floor through the elimination of wasted effort by only producing what was needed, when it was needed, instead of filling warehouses. Over time, other parts of the organization saw the opportunity to apply these same principles to business activities other than manufacturing. After all, nearly everything an organization does can be broken down into process form.

The Differences Between Lean, Six Sigma & Lean Six Sigma

Lean and Six Sigma are both disciplines for continuous improvement, but have differences in objectives and approach. Lean is a discipline in which the goal is to eliminate waste and increase process efficiency through a focus on improvements in speed and cost. MLDD1
Six Sigma, on the other hand, is a discipline in which the goal is to eliminate variation and reduce defects through a focus on improvements in quality.
Lean uses tools such as kaizen events, value stream mapping, work load balancing and 7 waste analysis. Six Sigma uses more analytical tools such as Pareto analysis, control charts, statistical analysis and defects per

million opportunities (DPMO) measurements.

Lean Six Sigma is a hybrid that brings both of these disciplines together. It takes a pragmatic view of process improvement with a focus on what is needed and important to the customer. It combines the time-focused strategy inherent in Lean with the analytical tools of Six Sigma, which allows for a flexible solution set to address the broadest set of problems.
DMAIC (Define-Measure-Analyze-Improve-Control) is the fundamental framework of Six Sigma and was adopted as such for Lean Six Sigma, specifically for projects aimed at improving existing business processes.

The DMAIC Framework

DMAIC is a project methodology comprised of 5 phases and is often deployed with specific deliverables identified for each stage.
MLDD2

How Companies Are Using Lean Six Sigma

We can say with certainty that while Lean Six Sigma has its origins in manufacturing, it has moved beyond the factory floor and is being applied across all parts of the organization. Today, companies are using the fact-based principles of Lean Six Sigma to:

• Drive cross-functional process improvement initiatives such as new hire onboarding
• Streamline back office functions such as accounts payable
• Identify new applications of existing products
• Reinvent functions to improve the quality of service delivery

The bottom line is companies are achieving success through Lean Six Sigma’s basic principle of identifying who the real customer is, determining what they perceive as value, and focusing on activities that help deliver that value while eliminating or reducing activities that do not.
A common underpinning of how companies implement Lean Six Sigma is the recognition of various “belts” as a measure of employees experience level. Industry standards define three common belts: Green Belt, Black Belt and Master Black Belt. Organizational approaches and the utilization of these belts, however, vary among companies.
Some companies take a top-down approach. They have a formal PMO (Program Management Office) with trained experts, such as Black Belts, deployed as internal consultants to drive improvement projects throughout the business. Other companies take a bottom-up approach. They have a formal program in which front-line employees, typically following a structured belt certification path, are formally trained and expected to drive process improvement projects. Both approaches offer strengths and challenges. Companies need to identify the best fit for their organization while managing the potential pitfalls.

Common Pitfalls

In its simplest form, Lean Six Sigma provides a methodology and a set of tools to drive continuous improvement through analysis based on facts and direct customer input. Far too often, however, this simplicity is lost in the zeal to achieve measureable results as fast as possible and companies fail to see success. Here are some of the common pitfalls we have seen:

Focusing on belt certification over business value

One of the most prevalent problems companies face in their implementation of Lean Six Sigma relates to the project requirements of belt certification. In order to become certified, Green and Black Belt candidates need to complete a formal project. This potentially creates an environment in which employees pursue projects to satisfy certification requirements as opposed to projects that have real business value.

Not balancing resource demands

Excessive focus on belt certification may lead to many belt candidates requesting the same few subject matters experts (SMEs) to participate in their projects. These key people get pulled into meeting after meeting and project after project until they finally put up a brick wall and stop contributing. Without input from these SMEs, it is difficult to properly define the problem and the opportunities for improvement

Gathering too much data or not letting the data talk

There can be a tendency to collect data for the sake of collecting data because Six Sigma is driven by data analysis. This can lead to poor data quality and analysis paralysis. Human nature can also lead people to enter the analyze phase with preconceived ideas on what the root causes are instead of letting the data tell the story to help define where the opportunity exists.

Implementing a rigid program focused on standardized templates

There is no one size fits all. Lean Six Sigma provides a framework and a set of tools. However, intelligence and experience still need to be applied to select the appropriate tools and techniques for the specific project. When companies impose an inflexible method, people start filling out the approved templates for the sake of complying with the corporate standards instead of garnering the intended value of the particular tool.

Deviating from the DMAIC process

The excitement of making improvements can lead organizations to jump right in and start implementing change without collecting or analyzing data (often because they come into the project with preconceived root causes and solutions in mind). While the end game is to implement improvements, organizations need to let the DMAIC process work in order to accurately identify the problem and the most effective improvements.

Assuming belt candidates have project management skills

For some reason, when it comes to Lean Six Sigma, fundamental project management is often ignored during the selection process for Green and Black Belt candidates. As a consequence, people lacking these basic project management skills may be tasked with leading projects. This may result in a situation wherein the effort is not properly managed and produces no tangible results. Since management has committed to embrace Lean Six Sigma, projects might still be praised as a success with no recognition of the mistakes or lessons learned.

Letting best get in the way of better

Lean Six Sigma is not a static methodology—it’s all about continuous process improvement. That is, continuously finding ways to make the process better, faster and cheaper. Many times, companies execute improvement projects with a vision of a perfect process and, as a result, spend too much time and dedicate too many resources to the initial effort.

Bringing It Together

You started with a simple question: “What exactly is Lean Six Sigma and how can it benefit my organization?” In this article, we provided an overview of Lean Six Sigma and how it integrates the efficiency focus of Lean with the analytical tools of Six Sigma to provide a flexible solution set. We also outlined Lean Six Sigma’s phased project methodology of DMAIC. In addition, we provided a perspective on how companies are approaching Lean Six Sigma and how they are using it to achieve bottom-line results. Finally, we identified some of the common pitfalls organizations have experienced in their efforts to instill a Lean Six Sigma culture.
We view Lean Six Sigma for what it is: a set of methodologies and tools that drive continuous improvement through analysis based on facts and direct customer input. We take a pragmatic approach and apply our experience as Lean Six Sigma practitioners to bring the appropriate tools to the project at hand rather than follow a prescriptive methodology.

Don’t forget to leave your comments below.

Michael Lilley, CPA, PMP, CIRM is a consultant with Systems Evolution Inc. (www.sysev.com) with over 20 years of industry experience in the areas of Project Management, IT Program Management, Operations Management, Process Engineering, and Management Consulting. Mr. Lilley has played key roles in driving initiatives such as Sarbanes Oxley compliance, ISO9001, Six Sigma, Lean Manufacturing, Total Quality Management, Project Portfolio Management, and Shared Service Centers.

David DeCoste is a consultant with Systems Evolution Inc. (www.sysev.com) with over 20 years of internal and external consulting experience. His background includes Strategic Project and Program Management, Process Improvement, Business Analysis, Program Development and Implementation, and Change Management. Mr. DeCoste is a certified Lean Six Sigma Black Belt proficient in short-cycle improvement techniques, including Kaizen and Value Stream Mapping.

Top-down or Bottom-up – Either-or or Both

Written by George Pitagorsky on March 14, 2012. Posted in Articles. 5 Comments on Top-down or Bottom-up – Either-or or Both

Whether the context is planning, requirements definition, or design, the issue of whether to take a top down or bottom up approach and which to take first is relevant.

Different People Think Differently

The question is about how people think and perceive the world and how they go about analyzing the world they perceive. While there is no one right way, there are arguments for taking a top-down approach first and then selectively going down into the details.

On a recent project, working with the definition of program and project scope, one influential stake holder took the position that for the sake of time, the team not spend time on defining the big picture but instead to start with one very important part and work outward from there to ultimately define the full system.

An alternative position was to take some effort to describe the system as a whole and then, once the major components and their relationships were known, to choose what to focus on next in terms of detail.

Some look at things from a top-down perspective, naturally seeing the big picture and how it works. Details are not necessarily their ‘thing’ but they must acknowledge the value and critical importance of details.

Others take a purely bottom-up approach, focusing only on the immediately relevant parts and either devaluing the big picture perspective or seeing it as something that comes out of the knowledge of the details.

Need for Both

There is need for both top-down and bottom-up perspectives and for people to flex their thinking to apply each in keeping with the need.

The big picture person who doesn’t value the effort required to address the details and the detail oriented person who fails to see the importance of the big picture are both detriments to optimal performance.

What is the proper balance? How much time and effort is needed to describe the big picture? What is the value proposition?

For one thing, a top-down perspective defines the context within which a project or system exists. Here we’ll define the word ‘system’ as a bounded collection of inter-operating objects and processes. Anything can be described as a system.

Practically speaking, every system exists within a higher order system and interacts with other systems. For example, an activity exists within a project, a project within an organization; an IT application exists within a business process and within a technology environment.

Small Investment for a Big Pay-off

That is why it is important to see the big picture before diving into the details or leaping into action. Without a clear sense of the big picture one runs a risk of unnecessarily disrupting the higher order system. Without a sense of the big picture one is likely to miss opportunities to plan or design optimally. Risks may be overlooked. Opportunities to build in flexibility and enable future expansion may be missed. Decisions are likely to be made with insufficient knowledge of their results.

Happily, a big picture perspective can be obtained in a relatively short time if it is done correctly. Correctly means visualizing the whole and breaking it down into a relatively small number (3 – 5 or so) of parts (activities, objects, components, etc.) that completely include all aspects of the system. Usually a breakdown of these into a second level of detail is needed to validate the top level and get enough definition to engage the detail oriented people and enable effective analysis.

Once this is done, risk analysis, estimating, high-level design and communication with senior level management can be accomplished before diving into next levels of detail, selectively based on priorities.

Avoid Unnecessary Conflict

It is important to avoid unnecessary conflict between big picture and detail oriented people. Often detail oriented people think that it is necessary to describe all the details in order to understand the whole. While there is some validity to that idea, one can get a sufficient understanding of the whole without knowing all the details. The big picture thinkers must be open to adjusting their ‘model’ of the system as details are defined that raise issues regarding the validity of the model. They must acknowledge that the system is not fully known until the details are defined.

With this in mind, a team can embark on a project or program that progressively elaborates the plan and the definition of the product over the course of project life. They can be careful to avoid wasting time by doing too much top down planning or by not doing enough and thereby discovering issues and risks randomly along the way.

Don’t forget to leave your comments below.

The Agile Project Manager—Getting Out of Jail Free

Written by Robert Galen on February 6, 2012. Posted in Articles. 8 Comments on The Agile Project Manager—Getting Out of Jail Free

I was teaching a class just a few weeks ago. It was focused on agile basics, user story writing & backlogs, sprint planning and all of the basic operations to kick-off a set of Scrum teams. It was going quite well on the first day and I was fielding the myriad of questions that typically come your way in an initial class of this sort.

Then I got hit with a question that I struggled to effectively communicate a succinct and direct answer to. The question was simple on the surface:

If within a sprint the team can’t seem to get the work they planned done, don’t you simply put it back on the backlog for execution in the next sprint?

I muddled around for a bit trying to answer the question. I merged my answer with the notion of sprint failure and success. I also spoke about team commitment. Both topics I’ve recently blogged about

But I could tell the questioner was frustrated with my answer—that they simply wanted me to say yes. Yes, just slide it onto the backlog. And that certainly would have been the easier way out for me.

So, we left it that they were frustrated and I moved on. But I’ve been thinking about this since then, and I thought it would be helpful to answer the question in this blog post. Or at least discuss more of the nuance behind my broad and feeble attempt at answering it.

Let’s First Go To Commitment

The first part of my struggle surrounds the teams’ commitment of delivery towards the sprint goal. Please reference my previous post for much more background here. But the essence is—the team committed to delivering a body of work supporting their sprint goal and I want them to well…deliver on their promise! I don’t want it to be easy for a team to defer work out of the sprint. I don’t want them to whine about missed estimates or technical complexity. I don’t want them to get accustomed to breaking their promises. I want them to seriously plan, seriously commit, and then seriously deliver on their sprint goals. Period!

If they do encounter “unexpected turbulence”, then I want them to think really hard about how they might be able to adjust to the new found work. Think creatively and leverage the ideas of every team member. If they need to make in-the-sprint adjustments, they need to pull the Product Owner into the conversations. As they explore options & alternatives, they should put their commitment and the sprint goal front and center.

Turbulence, I Mean Discovery Happens…A Lot!

And we need to remember that “s**t” happens within Scrum sprints…all of the time! The teams often find that they:

Underestimated the work
Overestimated the work
Didn’t account for technical complexity
Didn’t truly understand the customers problem
Didn’t account for someone taking vacation
Or getting sick
Didn’t fully understand the stories
Didn’t groom properly
Don’t have the requisite skills or knowledge to do the work
Didn’t account for testing complexity
Didn’t capture the right acceptance tests

and this list isn’t exhaustive. Things come up every day within sprints, which is why I don’t want deferring work to be the automatic or default reaction. This sort of “get out of jail free” card isn’t the intent of agile nor does it align with the commitment they’ve made to their Product Owner and themselves to deliver on the sprint goal.

Now can they move work to the backlog? Sure, absolutely, you bet! But determining whether they should actually take that road is an entirely different question.

Another Assumption

Another implication of the question is that if something slips out of the sprint that it simply & easily goes to the top of the backlog for execution within the next sprint. But that’s not always true. Once something re-enters the backlog, the Product Owner has the responsibility to reprioritize it, but it’s their decision as to how to handle the ordering. And it may not be as simple as…reprioritize to #1.

For stories that are focused on features to be delivered, then the Product Owner may have made commitments to external customers that are difficult to break or re-frame. The other factor is that there may be embedded time constraints as part of the story—meaning it needs to be delivered by a specific date.

What about the teams’ quality values? Should done-ness be easily violated in these cases? Here’s an example to illustrate a point surrounding done-ness.

Example

A team has done-ness criteria established for story delivery. It states that a story will be delivered with no known bugs i.e., they’ll be fixed prior to story completion and acceptance.

So, the team is working on a two-week sprint. The #2 priority story is predicted to take nearly the entire sprint to complete in sprint planning. The good news is that the team was right on this one. It’s day #8 and the story is nearly complete. The code is complete and multiple rounds of testing have been done. The team is feeling really good about the story and demonstrates it to their Product Owner for acceptance.

The bad news is that there are 13 known bugs related to the story. They’ve fixed 4 of them, but they can’t complete the other 9 by the end of the sprint. And even more telling, they uncovered a refactoring effort that needs to be completed as part of re-designing the codebase to support the story. So they essentially hacked the story into existence and are recommending a 15 point refactoring story to “do it right” in the very next sprint.

The team feels they completed the story and due to “extenuating circumstances” on day #8 they let everyone know that 9 bugs and 15 points of refactoring need to be completed before this story is ultimately finished.

I have a few questions for you:

If you’re the Product Owner, how do you prioritize this new/additional work? How do you balance it against your pre-existing release plans?

From the teams’ perspective, did they really finish the story? If not, what should have occurred within the sprint to potentially deliver a more complete story—pun intended?

How would you react or feel if I said the team should have ‘swarmed’ around getting this story completed—no matter what?

And finally, should this sprint be considered a success or a failure?

I’m hopeful these questions generate some healthy comments…

Micro Adjustments & The Product Owner

The above example leads into a related idea. I’ve been using the term “micro-adjustments” a lot lately to illustrate the dynamic between the Product Owner and the Team during sprint execution. The notion is that the sprint goal serves as a measuring stick that the team can use continuously throughout the sprint to guide their minor scope adjustments and trade-offs.

And believe me—adjustments are certainly required. Actually, not required—they’re a fundamental part of the lean nature of scrum.

So instead of adjusting whole stories in or out of a sprint, I think the healthier view is for the team to engage the Product Owner as early as possible as discoveries are made within each sprint. For each potential adjustment, the PO and team examine the issue through the lens of holding the sprint goal intact. So every trade-off is relative to the goal.

If the team can hold the goal by reducing the scope of a feature, then so be it. Then it’s up to the PO to determine if that scope trade-off needs to result in an additional story to the backlog or not. But I don’t want there to always be a story produced. In many cases, micro-adjustments will result in “good enough” software being delivered at the end of the sprint, with the resulting trade-offs never needing to enter the backlog. In fact, they were never needed in the first place.

So the other nuance I was trying to address in fumbling my answer was this notion of micro-adjustments and not falling into the trap of looking at stories as fixed in scope. Instead, the entire sprint is an emergent exercise that is guided by the sprint goal.

My overall experience in sprints is that very little needs to exit the sprint and re-enter the backlog. Sure, there is the occasional bug or refactoring story. And yes, stories do occasionally “pop out” onto the backlog. But the majority of the time, the scope trade-offs are internalized and adjustments made that don’t ultimately impact the backlog.

Indeed, more often is the case where the team PULLS WORK from the backlog into the sprint because they’ve discovered more capacity versus the scope they’d planned on delivering. Now that’s agile!

Wrapping Up—so what is the answer?

To use my standard consulting answer with tongue firmly in cheek—it depends.

In fact there are no universal answers to the question. Sometimes it’s a perfectly healthy and balanced response to push work from within a sprint to the product backlog. It makes sense and the overall agile integrity of the team is not compromised.

But in many other cases, this get out of jail free card can have some bad side-effects. It puts the sprints success in jeopardy. It can undermine the teams’ commitment to results. And it can place the Product Owner in a precarious position. It also usually implies that the team isn’t operating with a full “agile mindset” within their sprints.

I would always rather that the team viewed “punting work” outside of the sprint as a last resort—one that they carefully consider and leverage infrequently.

Now if I only had a second chance to answer that students question…

Thanks for listening,

Bob

Don’t forget to leave your comments below

From the Sponsor’s Desk – Knowing Your Project Profile

Written by Drew Davison on January 18, 2012. Posted in Articles. 6 Comments on From the Sponsor’s Desk – Knowing Your Project Profile

In my last post, Avoiding New Technology Risks, we looked at the steps one project manager took to leverage a promising new technology while avoiding the pitfalls often encountered with new technology introductions.

In this post, we’ll look at the approach one CIO took to confirm his gut feeling that a project was going to be well over budget and behind schedule. Thanks to reader B.L. for the details on this case.

The Situation

This Canadian insurance company was experiencing significant growth and having difficulty maintaining service levels at an affordable cost. The underwriting organization, in particular, was having a challenging time. Experienced underwriters were hard to find and training new staff was a long, slow process. The sales agents were unhappy with the response and level of quality on new applications for insurance. It cast the organization in a bad light with their clients. And, of course, agent compensation was negatively affected.

The VP responsible for the underwriting function, in consultation with the CIO, decided to explore the use of technology to alleviate the pressure, improve service and reduce costs.

The Goal

The VP of the underwriting function, the sponsor of the initiative, decided to launch a development project to automate much of the underwriting process. The plan was to have the applications for insurance processed by staff in the sales offices across the country using the new automated service with the potential for immediate approval and contract production if everything checked out. The target was to get the project implemented and operational in a year or less.

The sponsor and his staff calculated that they could save over $1 million annually in reduced administrative costs in his organization while cutting processing time from 10 days to 1 day on 60% of the applications. As well, sales agent compensation would be accelerated, service to clients would be improved dramatically and dependence on scarce underwriting resources would be reduced.

In consultation with the Sales VP, it was determined that the additional time required from administrative staff in the sale offices to process the insurance applications could be factored into the existing workloads and would require no incremental staffing. The project was a no brainer!

The Project

The sponsor appointed a manager from his organization to act as overall project manager. His job was to implement new underwriting and administrative processes and practices that would affect the sales agents, administrative staff in the sales offices and underwriting and administrative staff at head office.

The CIO appointed a project manager from his organization to guide the development of the technology solution.

The two managers collaborated on the estimate based on their previous experiences and arrived at a cost of $2.5 million and a year or so duration. They agreed to adopt the in-house system development methodology, a typical waterfall practice. They formed a steering committee with the key stakeholders – the sponsor, the VP Sales and the CIO – and proceeded to form their teams to tackle requirements definition.

The sponsor was adamant that the new automated system reflect their current underwriting practices to maintain or improve on their claims experience. So, the project managers adopted a prototyping philosophy that they could us to demonstrate practice compliance to the sponsor and his senior underwriters as well as to the staff in the sales offices. As the requirements definition progressed, the project managers encountered a multitude of “what if” questions in response to their prototypes, mostly from the senior underwriters. That required another round of prototypes and reviews and lead to more “what if’s”, and so on.

The planned three month requirements phase extended to four months, then five but the project managers insisted the overall project was still on target. Their rationale was that the requirements would be so well defined and fully approved that the 10% change contingency they had included in the budget would not be required. They also argued that the level of detail in the prototypes would enable multiple parallel development streams and reduce the cost and time required for the development and testing phases.

Project Profile Chart

The sponsor and the VP Sales bought the argument. The CIO did not. He had his Project Office pull together a profile for projects completed by the system development group in the previous two years. The profile showed that, on average, the development and delivery phases consumed over 60% of elapsed time and over 70% of resource costs. He concluded that the project would take another year to deliver and exceed the estimate by $1.5 million.

The Results

The CIO was right. The project took a year and a half to complete and cost almost $4 million. The IT project manager tried to reduce the elapsed time by developing the application components in parallel as he had argued previously. However, resource constraints limited the contribution the approach could make to accelerating the schedule.

The upside? The project was delivered successfully. The quality of the solution was excellent. The staff affected by the change in the sales offices and head office were enthusiastic about the system. The clients appreciated the service improvements. The project actually delivered over $2 million in annual benefits, largely because of the scope expansion resulting from the “what if” cycles. Even with the increased cost, the actual payback was greater than originally anticipated.

How a Great PM Could Have Helped

The project managers did a number of things well:

Forming the steering committee help all areas affected by the change get involved and onside.
Use of prototyping to facilitate requirements definition really did engage the experts and resulted in full backing from all involved. It also did contribute to a much lower level of change requests and helped deliver significantly greater value than originally planned.
The quality practices leveraged from the in-house development methodology were applied effectively throughout the development process, ensuring a high quality solution in all respects, including the required ease of use for each target audience, appropriate performance and security, provision of an audit trail, integration with back end administrative systems, continuity of processing and adaptability to future changes.

Unfortunately the PM’s missed a couple of opportunities to help the project excel and damaged their bosses’ perceptions of their performance in the process:

They didn’t recognize that the “what if” cycles were signs of scope creep. There’s nothing inherently wrong with expanding project scope but it has to be managed to expectations. In this case, it wasn’t.
There was a good deal of urgency in getting relief from the growing costs and service problems. But, the plan didn’t recognize the need for a fast response. Instead, the PM’s planned to define all requirements up front. Had they adopted a phasing strategy from the get go, they would have had an opportunity to deliver a first release sooner than planned and would have had a framework to manage the “what if” cycles more effectively.
The IT PM started looking for resources to support his parallel development plan as the requirements stage wound down. Instead, had he really understood the urgency of the situation, he would have had a resource plan in place from the start with the required staff ready to step in when needed.
Finally, the PM’s didn’t have a Project Profile for the organization in question. If they had access to that information, it would have forced more rigor on the cost and time forecasting and reduced the wishful thinking that they ultimately engaged in to justify their circumstances.

This could have been a great project! In fact, after the initial disgruntlement over cost overruns and schedule slippage, the stakeholders were extremely pleased with the results. The PM’s could have been heroes. Instead, they were goats. It would have helped if the other stakeholders had challenged their approach and assumptions earlier. Unfortunately they didn’t. The PM’s missed the opportunity to take advantage of a few simple practices that could have made all the difference and they paid the price.

If you find yourself in a similar situation, remember to consider Project Pre-Check’s three building blocks right up front and put these points on your checklist of things to do so you too can be a Great PM, and your sponsor’s best friend.

In the interim, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, send me the details and we’ll have a go.

Drew Davison

Don’t forget to leave your comments below.

Is Your Meeting Worth the Time?

Written by Andrea Brockmeier on January 11, 2012. Posted in Articles. 4 Comments on Is Your Meeting Worth the Time?

A couple of days ago I fired up my online calendar and started to schedule a meeting with my manager. Our meetings are typically less than 30 minutes long, but I had a lot to talk about, so I was going to make it an hour long. Yessirree. I had a lot of stuff on my mind, I needed an audience, and he was the logical person to hear me out!

Fortunately, we have a little meeting protocol where I work. In our organization, you can’t schedule a meeting without identifying the objective of the meeting and the desired outcome. At first, I didn’t think it would be difficult to get my thoughts around those things and document them. (Did I mention I had a lot to talk about?)
But when it came to actually spelling out the objective in the invitation, my fingers froze. I hadn’t really gotten much past “To talk about all the stuff I need to talk about.” That, of course, left me with nothing to describe in the way of desired outcome.

So I took my hands off the keyboard, put them on my forehead and started to think: What is the purpose of this meeting? Why should he take his time, that is, the organization’s most valuable resource, to meet with me? What do I have to say that is worth his time to discuss?

The truth is, I did have a lot on my mind. I was feeling overwhelmed and unfocused with more to deal with than I had bandwidth for. I had ideas and thoughts about some things I was excited about and wanted to be able to address all of it, but I couldn’t.

The truth is also that I did not have a lot to discuss. I just needed to know the current priorities of things on my plate. My objective was to clarify my priorities, and the desired outcome that I needed at the end of our meeting was a list.

Once this became clear, the meeting got a lot shorter.

How long ago was it that you attended a meeting with 3, 5, or 10 people without a clear understanding of the purpose and deliverable expected out of the meeting? When was the last meeting you attended that got off track in the absence of a meeting objective? How many meeting agendas have you seen that included extraneous items that wouldn’t have been necessary had a purpose been identified? Most importantly, when was the last time you were sitting in a meeting that you might not have needed to attend if a clear meeting objective had been defined?

The time it takes to be thoughtful about a meeting objective and desired outcome is not free, but it will always be cheaper than the time squandered in meetings without clear objectives defined.

So the next time you are inviting people to a meeting, consider identifying the objective of the meeting. If someone were to ask you why your meeting is worth their time and organizational money, could you answer? Maybe your objective is to get a decision about something. Or identify options. Or prioritize choices. Whatever it is, define it first – before developing an agenda, deciding how long it will be, or whom to invite.

And then write down what it is you need to walk out of your meeting with, your desired outcome. Maybe it’s a decision. Or signatures of approval. Or a list of options. Whatever it is, write it down. You’ll find your meetings are more likely to end on time because you know when they’re over – you’ve named it!

Try it. But don’t expect to like it. It’s a lot easier to just send an invitation to a bunch of people for a meeting about…you know…that thing we need to talk about.

But once you have defined an objective, the rest of the meeting will become a lot more clear. Your desired outcome will probably reveal itself. Who really needs to be there will become evident – and will probably result in a shorter list of invitees than a meeting with no defined objectives. Your agenda will begin to take shape and, again, probably be shorter than with an undefined meeting.

I ended up scheduling our meeting for 40 minutes, which is longer than we usually meet, but shorter than I initially intended to request. I’m pretty confident it’s going to be a good use of organizational time and resources. I think my manager is, too.

Don’t forget to leave your comments below.

Andrea Brockmeier is the Client Solutions Director for Project Management at Watermark Learning. Andrea is a PMP® as well as Certified ScrumMaster. She has 20+ years of experience in project management practice and training. She writes and teaches courses in project management, including PMP^® certification, as well as influencing skills. She has long been involved with the PMI^® chapter in Minnesota where she was a member of the certification team for over eight years. She has a master’s degree in cultural anthropology and is particularly interested in the impact of social media and new technologies on organizations and projects.