Subscribe via RSS Feed

Tag: "definition"

What Drives The Getting Predictable℠ Best Practices?

startIt’s all in the phrase: From the Start. I am frequently asked how the Getting Predictable Best Practices got started.

Getting Predictable℠  best practices cross many subject areas including requirements collection, tracking project progress, facilitation techniques, providing estimates that drive confidence, and so on. With such a wide array of practice areas, you’re probably wondering what binds them together. In other words, is there a common theme or vision that drives current and future best practices and recommendations? The answer is YES – there is indeed a common theme. And, as you guessed, this blog post reveals the vision aligns Getting Predictable℠ in all of its many flavors from discovery to definition through execution.

From the Start

Getting Predictable℠ is a collection of best practices that set teams up for success from the start.

Wow! How profound! (Yes, I am being sarcastic at the moment but there’s truth here as well) For the majority of my career I have been on the client side of consulting relationships. I have heard some pretty big promises and I tend to be very skeptical. As I read my own description of Why Getting Predictable℠ exists, it’s hard not to think how empty it sounds! So let me explain. Let’s pretend we have a project kicking off and we have approximately four weeks to collect the overall requirements so the technical team can begin their planning and staffing of the project. So we e set up meeting with key stakeholders and business users for the first week in March to kick off the requirements gathering. The business is extremely busy and coordinating their schedules is like herding cats. All too frequently, you do not get full traction and commitment from the team during the first few days. In fact, it is possible that you might not get to full throttle until the second week of the four week schedule. Since we didn’t pad our four week plan, this lost time needs to be addressed. It is important for us to be adaptive and stay on schedule despite losing three to five days at the beginning. I want to emphasize that is not a rare situation. Especially when launching a new initiative. Would you agree?

Let’s take a different perspective…

Let me share a different way to view this. It may be a day here or a day there, but if we actually lose four to five days getting up to speed across the four weeks, we have lost 25% of schedule. We are potentially 25% late and over budget for this phase. And we haven’t even started yet! Here is my point: Although most of our leaders and managers would never intentionally handicap or put the team at risk, they are unaware that missing a meeting or pushing a date is actually doing harm to the team. If this story, in one flavor or another, resonates with you, then your success and the success of your project are being put at risk from the very start of your project. Why does this happen?

It’s all about the frog

If you put a frog in boiling water, it will immediately jump out. It’s way too hot. But if you put a frog in room-temperature water, and very slowly turn up the heat to a simmer, the frog will stay in its comfortable hot tub until it perishes. Ouch! On your project, it may only be a day here or a few folks there, not available, but before you know it, your project is starting to simmer. So let me repeat:

Getting Predictable℠ is a collection of best practices that set teams up for success from the start.

Getting Predictable best practices identify and address the situations, activities and events, that can slowly handicap the teams chances of success before they even get going.

Now You’ve Got My Attention. Tell Me More.

Getting Predictable℠ Best Practices cover the gambit: Discovery, definition, execution, and organizational effectiveness models. In this blog, I focus on the best practices that address defining and launching a project or initiative. I call this set of best practices Getting Predictable℠ Definition. Getting Predictable℠ Definition addresses the three key areas that impact a project right from the start:

  • Alignment: Driving alignment around project success across all stakeholders.
  • Commitment: Developing estimates and plans the team can commit and manage to.
  • Visibility: Having a common view of progress as well as a a common definition of when the team has delivered on the defined project objectives.

In my next posts, I will discuss each of these areas in detail so you can see there is a method to the madness of Setting Teams Up For Success FROM THE START.

Discovery: Going Where No Person Has Gone Before

Discovery-Going-Where-No-Person-Has-Gone-BeforeTypically, at the beginning of a project, we begin by collecting requirements from the business. We might spend a month or more gathering requirements. If we are using a more Agile approach, we may spend a few weeks gathering requirements for the first few iterations in the form of stories.

Every once in a while, I find myself starting a project where  for every step  forward we seem to be taking two steps backwards (or at least sideways).  Let me explain: As soon as the development team starts to code, literally within the first week or two of coding, the change-requests start. Does this mean the business is already changing their mind? We are just beginning to code!

So how is it that the business is changing their needs within weeks of starting a project? I can see change requests occurring once they see some initial software delivered.  But why do we regularly see projects with  change requests before the business even sees a deliverable?

We might assume that we had the wrong stakeholders in the room.  Another potential cause could be that we didn’t do a great job collecting requirements. Certainly, there are projects where one or both of these problems exist.

But what I often find  is that the project is suffering from a case of “Discovery”.  More specifically, the business is stuck in Discovery and is not ready for Definition.

Discovery vs. Definition

Let me contrast the difference between Discovery and Definition. Put simply:

Discovery is the phase where the business identifies what problem to solve as well as a description of the end-state or goal of the project.

If Discovery defines what problem to solve, then Definition defines the path to the solution. In other words, the Definition phase focuses on how we are going to achieve the end goal.

An Example:

A small company is in growth mode, doing very well. At a recent Board-of-Directors meeting, the company’s management team was asked how they can continue their revenue growth over the next two or three years.

They currently develop advanced Word Processing solutions for Android products. Their solutions are customized to that platform and to take advantage of all the Google Android features, giving a rich experience on a mobile platform.

To increase revenue, they can choose to develop a complimentary Spreadsheet tool for the Android platform, providing the same, rich user experience and Google feature integration.  On the other hand, they can choose to create an identical Word Processor and user experience on other mobile platforms such as iPhone and Blackberry mobile devices.

There are probably other paths as well, all providing a path to their continuous revenue growth. At this point, we are “Taking a single goal and generating multiple ideas.”

Moving from Discovery to Definition

After much research and due-diligence, you conclude that the best direction would be to offer your current Word Processor and all of it’s rich user experiences on the iPhone and Blackberry platforms, solidifying your brand as “The Mobile Word Processor. Period.”

At this point, we have completed the Discovery phase because a decision was made on the overall goal. Now, it’s time for Definition.

In Definition, we  begin to define the path to that goal.  We start to define the key features that MUST be in the iPhone version and how we will replace Google Android features within the Apple iPhone environment.

Clearly identifying this  feature list is what is called Definition.

So Why Should We Care?

If you are trying to define the requirements for a solution, but your business stakeholders are still discovering what they call success, then you are destined for rework! And this will show up as:

  • A proliferation of change requests early and often
  • Slipped schedules, since they didn’t anticipate these discovery changing goals
  • Budgets being blown since they didn’t anticipate the increased costs associated with rework

Because they are still in Discovery, we can’t be sure of the right direction. Any step we take could cause rework that translates into budget and schedule variances.

My guess is that you could think of a project or two right now where the business stakeholders were probably not ready to define their system. And, most likely,  this “re-thinking” of their projects goals created a great deal of pain for everyone involved.

So What To Do?

When you are collecting requirements, or engaging with the business, if you believe they are not ready to define how the system will work, you need to “pop-a-level”.  I use this term when I want folks to take a step back, and take a different view.

So if you suspect you are being setup for a great deal of rework, then pop-a-level and ask your business team:

  • Do you have the right Subject Matter Experts who are knowledgeable and empowered to help define your needs?
  • Are you  still in Discovery? Are you unsure of what a clear definition of success is?

In either case, try to create transparency around the issue, highlighting the potential costs of continuing to move forward when the wrong stakeholders are involved or the goals are fuzzy.

Realizing your project is in Discovery is half the battle. No matter what’s ahead, this realization will enable to you stay on course and manage the project more effectively.

Have you experienced Discovery? Please share your experiences in the comment area below.

How to Turn a WAG (Wild-Ass-Guess) Into a SWAG (Scientific-Wild-Ass-Guess)

Next in our Providing Meaningful Estimates series we talk about turning WAGs into SWAGs.

SWAG-Bar-Chart1S-W-A-G stands for a Scientific Wild Ass Guess.  It’s sometimes used more as a tongue-in-cheek way of saying: “This estimate isn’t really reliable. I pulled it out of the air.”

I’m going to  show you how to put the S — the science — back in a WAG so even an off-the-cuff estimate can be meaningful and useful to your audience.  The easiest way for me to demonstrate how to improve your SWAGs is to use a simple example.

Consider providing a SWAG, an order of magnitude estimate, on how long it would take you to read to The Fountainhead (752 pages) by Ann Rynd. In fact, stop reading this  article right now  and come up with your estimate.   Please don’t do any research.  Just take a moment and give me your “best” wild-ass-guess (WAG) right now.  I’ll pause for a sec.

No seriously, take a moment, and come up with how many days it would take you? 1, 7, 14,…… 365?  Just take a moment.

Now, I’m going to l give you a technique that to  add some  S to your WAG and make it a more  a scientific answer.

Actually, It’s All In the “Words” We Use When We Present  to Provide Our Estimates.

Whenever someone asks you for high-level-estimate and you can’t really do proper research, you will need to make assumptions.  The key is to expose  these assumptions with your estimate and to demonstrate how changes in assumptions might impact your estimate.

Here’s a framework that demonstrates how this  works:

  • When providing an estimate, always provide a range. And for each number in the range, provide assumptions. It sounds simple, but the difference is pretty significant.Always start out by thinking: What is the lowest reasonable number your estimate might be. More importantly, explain provide why do you think it is unreasonable to assume that the estimate might be lower.So for The Fountainhead, you might start the estimate with:“I can’t imagine it taking me less than 7 or 8 days. Assuming I find the book interesting, I can probably read 100 pages a day and a little more on the weekend. But with my workload at work, and errands in the evening, it’s not realistic to expect me to read more than 100 pages or so each day during the week.”
  • Next,  think about what is realistically the longest this task should take you. When you give this estimate, you also share what assumptions need to be true for you stay within this estimate (not exceed your high number).Returning to our example with The Fountainhead, you might continue your estimate with:“I can’t imagine it taking me more than 40 days.  If it does take longer, then the book must have been written in a 3-point font or in French (I don’t speak French) or a crisis at work came up.  I have to believe that I could force myself to read 20 pages a day, and even if I find it boring, I’ll get through the book in 35 to 40 days.”

Wild Ass Guess Vs. Scientific Wild Ass Guess

Now, let’s  contrast these approaches in terms of reading The Fountainhead- a. All 752 pages.

WAG: It  might take me anywhere from 7 days (a week) to 30 days (a month).

Using our new framework, you would answer:

SWAG: “I can’t imagine it will take me less than 7 days, assuming life doesn’t throw me any unexpected curveballs and I can  read 100 pages a day.  I can see it taking  me as long as 38 or 40 days if I can only get through 20 pages a day due to boring content or unexpected crises at work. If it takes me longer than 40 days, then it not only was painfully boring, it probably is written in some ridiculous font or written in French (I don’t know French).”

I hope you agree, that the second  example provides a level of confidence that we thought through our WAG and have some reasoning behind our estimate.

Check Assumptions. Manage Expectations.

The correct wrap up for a SWAG is an opportunity to further manage expectations by saying:

“If The Fountainhead  is as  good a book as you say it is,  , then let’s assume I’ll get it done in about 14 days. Within the first 2 or 3 days, I can update you on whether this was a reasonable swag or not.”

This means within the first 2 or 3 days, you determine if the SWAG assumptions are correct. You  can even restate your  SWAG now that you have started reading it and verified your assumptions (one way or another).

If you still aren’t convinced, let me show you how effective this approach can be might be by by using a  one more example real life example.

A Real SWAG in Every Day Life.

You own a home and want to build a deck on the back of your house. You ask two contractors to come out to your house and give you bids on the work. With each of the contractors, you walk through the backyard and show them where you want the deck.  They show you different styles of decks and after reviewing the pictures, you choose your preference.

Each contractor tells you they will give you an exact estimate for cost and a proposal by the end of the week. But you have a key question:  Your son is graduating college in two weeks and you want to know if the deck will be completed in time for the graduation.

Contractor #1 answers:

WAG: “The deck could take anywhere from 2 to 5 days. So if we start Monday we should have it done by the weekend. Let’s just hope we don’t get any bad weather.”

Are you at all nervous that the deck will not be done in time?

Contractor #2 answers:

SWAG: “I can’t imagine it taking less than 2½ days. If we can get the deck primarily built the first day, we’ll need the 2nd day to stain, make final adjustments etc. So by the time it’s dry and tweaked we are at the 2 or 3 day mark. It’s important that we don’t get any rain on Tuesday when we stain the deck.

Sometimes when we put the “supports” in the ground, we find obstructions we need to move. That could make the job take up to 5 days.  If it takes longer than 5 days, then you have a surprise waiting under the ground.  I don’t think you do, but until we start the job, I can’t be 100% sure.  Of course, this assumes the weather doesn’t blindside both of us.

So barring any golden surprises, we should be able to complete the job between 2 to 5 days. I would hope to have it wrapped up by day 3 but I’ll know more on Monday.”

Which contractor gives you more confidence in their ability to deliver on what they said?

More importantly, if the estimates are off, they can talk with meaning. They can discuss what assumptions were wrong, or what had they not considered. In other words, it doesn’t feel like they just pulled a number out of the air without any thought or real consideration.

In summary: The Framework

So, in order to turn your WAG into a SWAG, start your estimate with:

  • The  shortest or lowest estimate that is reasonable
  • Why it isn’t reasonable to be shorter/lower
  • Explain how large it is possible to go
  • What are the assumptions that would make it go that large
  • What are your assumptions that could cause it to larger
  • Finish your estimate with a viable, in between reasonable “target” in between that you believe is reasonable to start with. Explain how and when you will be able to validate assumptions and firm up your estimate.