Subscribe via RSS Feed

Category: Defining Success

Stop Padding Your Estimates! There’s A Better Way…

When you pad an estimate, you typically increase your estimated effort/cost due to fear. I call this estimating from a place of weakness. You are afraid of the unexpected event, so hopefully padding it will cover it.

When asked why you think something might take 50% longer or cost more than expectations, it leads to an awkward uncomfortable conversation. And almost always, it creates distrust. How do I know you haven’t padded everything?

A Better Way: Contingency

Instead of padding out of fear or worry, add contingency instead. Let me clarify what I mean.

An example of padding an estimate: Your estimate is for 2 weeks to finish a straight forward project. Because you know stuff happens, you decide to say it will take 3 weeks. That gives you a full week to recover from delays or fix any defects.

How do you know a week is enough padding? You don’t. But you believe you can get away with it easily enough. Saying 4 weeks would be pushing your luck.

Instead, here’s the same example using contingency: You provide your estimate as being 2 weeks. You also explain that typically, there are delays of source material, and defects that need to be addressed before we are all done. So you are adding one week of contingency time, just in case.

You are sharing your estimate and “contingency” from a place of strength and confidence. You show it’s in everyone’s best interest to include the contingency. It builds confidence and trust.

It’s not uncommon for one of my full project plans to have contingency tasks added throughout the plan. If the customer wants to push back, here’s how the conversation goes:

Customer: “I see every time you are working with the API team, you show a task for 3 days, but you add a contingency task of 3 days as well. Can you explain what that’s for?”

Our team: “Typically, 3 days is enough time to integrate the APIs and move on to the next task. However, in the past, this API team is always overwhelmed with work, and some of the APIs are new and complex. So the contingency time is based on history and allows us to plan for those delays. If they can actually reduce turn around time and hit the 3 day mark, we’ll be ahead of plan and deliver early. After all, there are 5 API tasks and 5 contingency tasks.”

Customer: “I’m not sure I am comfortable with this approach. I think we should remove the contingency tasks.”

Our team: “We can do that. However, if in fact those teams don’t hit their tasks, we are going to say ‘We Told You So’ and you can’t hold us to the dates!”

And no we don’t say it this way – but that’s the message.

At this point, I can’t remember a time when the customer didn’t agree to keep the contingency in the plan. After all, they want to be successful too.

In summary…

Don’t pad your estimates. Clarify why you are padding by adding contingency and sharing the risk. Hope this helps you with your estimates. Would love to hear your experiences as well.

What Projects and Airplane Flights Have In Common: Turbulence

I love this metaphor to help leadership, management and project teams all see the forest for the trees. Here are the key points I share:

Nobody will remember the turbulence, if the plane arrives on time and in the right city!

I used to fly quite often. One of my frequent destinations was New York. Depending on weather and other factors, it wasn’t unheard of having a flight to Kennedy re-routed to Laguardia or even Newark. In those days, it happened. But the one flight I remember best was one returning home to Chicago.

I remember one bad storm that caused our plan to circle O’Hare for what seemed like 2 hours. That delay, by itself, wasn’t out of the ordinary. The reason I remember this one trip is because when we landed, I found myself in Cleveland.

I’ve had my share of turbulent, strap-yourself-in and hold your breath, flights, that landed late. I don’t remember any specific ones. But, you better believe I remember when they re-routed us and we landed in Cleveland. I rented a car and drove ½ the night to make it to Chicago by the end of the day.

So What Did Success Look Like for My Many Trips?

  1. At a minimum: Land safely!
  2. It’s better if we land in the right city.
  3. It’s even better if we land in the right city at the right airport.
  4. I consider it a successful trip if we land within 60 minutes of our planned arrival time, in the right city in the right airport.
  5. It’s almost too good to be true if they had my preferred meal, I got a great view of a sunrise or sunset, and there was little turbulence.

And this is exactly how our stakeholders feel about our projects

  1. At a minimum, deliver “something of value”, even if late, without cancelling it due to budget and delays.
  2. If I can get all the functionality needed for the market, we’re doing better. Even with some bugs, I can work with that.
  3. And if it’s on schedule (or close to schedule) and budget, we’ll be celebrating!

But the one thing the teams should remember. Most flights have turbulence, and they run out of your preferred meals, and there’s unexpected weather and other challenges. In a year, no one will remember those details.

Make sure the project lands safely, with the appropriate functionality. Because everyone will remember the project that crashed landed.

I have another post that compares the PMO to Air Traffic Controllers. It shares best practices that helps you put in practice the lessons shared in this article. Stay tuned.

Stay Inside the Lines to Manage Projects Effectively

Throughout the Getting Predictable blog, I talk about alignment. For many, the word “alignment” is a bit vague. Does it mean we agree? Does it mean I actively support you? If I don’t actively support you, but I don’t block you either, am I “aligned” with you?

As it relates to projects, doesn’t alignment simply mean we agree on what is in scope? Why are there so many books written on alignment, and why do they sound like “consultant speak?”

alignment

The cost of mis-alignment

Alignment is important because when a project team is not aligned, it can not only derail a project, but, in a very subtle manner, prevent the project from ever getting back on the rails.

Sometimes, keeping projects inside the lines can be challenging. In fact, it can be a lot like looking at a roadmap when you’re lost. You’re the driver, you have a navigator next to you, and GPS, and each one is doing something different. You’re not in sync, and it’s difficult to figure out where you’re going. In the confusion, you end up getting even more lost, and it takes you twice as long to get to your destination.

This example illustrates how bad alignment can steer a project – or a car trip – right off of a cliff. The concept of alignment is often a bit of a no man’s land – people don’t understand just how harmful bad alignment can be to a project.

The 3 Great Interrupters: Meetings, Management and Drive-Bys

interruptors-300x199Recently, we’ve introduced Commitment Based Estimation  to a couple of our software teams. Typically, this helps a team provide highly-accurate estimates. These teams go on to deliver successfully by meeting these estimates.

Delivering Successfully is like the Matrix: It’s All In Your Head

matrix-300x269

In this blog I usually  write about best practices that help set teams up for success. That is really what Getting Predictable is about.

Project Glossary: The Right Way to Create One

Project-GlossaryDuring the course of most projects, at some point, someone starts creating a project glossary of terms.  Typically, most of us are well into the first or second requirement document before we realize that people don’t understand some of the terms or acronyms being used.  When that happens, the Business Analyst or Project Manager starts the glossary so everybody can understand these specials terms and acronyms.

I have come to believe that a project glossary really should be created right at the beginning of the project. In other words, on day one when you start working with the business, collecting initial high level requirements and defining the business case.

The project glossary is critical. And even though everybody uses it just to explain acronyms, I think it should do something a little different.  How about a project glossary that is used to actually explain the intention of a word, not just to define it?

What is CRM really used for?

Let me give you an example. “CRM” is a term that many people in the industry are familiar with.  Although CRM stands for Customer Relationship Management, many organizations do not use their CRM system to track existing customers. They’re using it to actually track prospects or non-customers. So if  “CRM” wasn’t as ubiquitous and somebody brand-new (who never heard the term) came in, they might say, “Well, why are we in the CRM system to track prospects? Why wouldn’t we use the CRM system just to track customers? Isn’t that what the C in CRM stands for?”

Ideally, our glossary would have an entry for CRM that explains CRM stands for “Customer Relationship Management”. However, it would also go beyond defining the acronym and actually explain that on this project, or in this organization, we use CRM as a business development tool for prospects as well as to track dialogues with existing customers.

Then there are some companies that use the word “customer” to represent certain customers and use the word “client” to represent special VIP customers. This should also be explained in the glossary so that everyone understands the difference between the customer and client and the perception around those two segments.

But Wait, There’s More

Another tip about project glossaries: Don’t just define or explain how you’re using a term or an acronym. Also explain what the term doesn’t include. For example, if “word processing tools” were in my glossary, I’d say, “This term describes the spell check, formatting and print tools but does not include the process of sharing documents via e-mail.”  This way there’s less confusion.  You can read my previous post on ambiguity here.  It’s an interesting story on how ambiguity can create grave problems in any project if you’re not careful.

To summarize, the glossary is critical to good project communications and should be used for more than just explaining acronyms. Other things to keep in mind:

  • Create your project glossary at the very beginning of a project.
  • Use your project glossary to explain ideas, including how the term is specifically used within the organization.
  • Include the scope of the term, specifically what the term does not include.

Do you use glossaries from day one? Do you have any best practices with your glossaries?

Change Control: Do You Own It or Does It Own You?

Change-ControlOver the last year, I have noticed a myriad of projects that begin to struggle once they begin the change control process. Doesn’t matter the type or size of project – they all appear to drop-the-ball when it comes to following the change control process. This pain surfaces not only in the schedule and budgets, but also in the lack of trust that builds between the business and technology teams.

I want to share some best practices than can help teams manage change control in a more disciplined format. In this first post, I discuss the key roles that should be involved in change control.

What is the typical change control process?

In a typical scenario, the business or project stakeholder comes to the table and says they want to change some functionality. This can be a change to something already built, or it could be a change to some requirements you have collected but haven’t implemented.

When asking for the change, the stakeholders typically want to understand any impact to cost or schedule before committing and asking you to “implement” or “deliver” the change.

What are the roles typically involved in change control?

In a typical change control process, the roles look something like this:

After a change request is submitted, someone is responsible for tracking and reviewing (think triage here) the change request. Acting as an editor, they review the change request and make sure the request is complete and without ambiguities. If there are any gaps or missing information, they go back to the “requester” or to the stakeholders to get the missing information. Obviously that’s pretty standard practice.

Next, one of the technology team members needs to assess the change request and determine what, if any, impact it will have on the current plans. By assessing, I mean sitting down and evaluating the impact of this change request against schedule, budget and staff. They may also identify questions for the stakeholders that need to be answered before they can complete their assessment.

This is where you typically have a “go to person” to do this initial assessing. This resource will typically be asking questions like:

  • Are we short on staff to handle this request?
  • What impact will there be to schedule?
  • What additional risk and/or dependencies does this add to our project?
  • Do I need any “specialists” or unique tools for this request?
  • And so on

The Changing Roles of Change Control

This is where I suggest including a larger team to do the change evaluation. Many of you may already use this approach. Kudos!

But for the rest of us, I suggest that we get a total view when assessing the impact of a change request. This means include a business analyst, quality analyst, etc. in the assessment.  I know there are some Agile teams that do this with all team members. Woohoo!

Why is this so important? Because one person probably can’t truly know the impact this change will have on other parts of the development or the development process.

For example the change may be trivial for the developer because it will take just two hours effort. However, the Quality Assurance team may have to rerun all of the regression tests, impacting the schedule by up to two days. A business analyst may actually look at the change and say, “Given the change, do we need to change three other things in the system so they’re all behaving consistently?” All of a sudden, the business analyst may have to modify other requirements. The dominoes may begin to tumble.

I suggest you make sure all roles on your team are included. It would be sufficient if a single team member plays multiple roles as long as this person knows they’re representing these other roles and thinks through the implication to other scheduling, staffing and costs.

Communicating Change

Make sure change requests are communicated across the entire team. Communication to and within the team is a discipline. Some of my experiences this year have reinforced that communicating changes isn’t optional.

Many team members think a trivial change (like a cosmetic change) doesn’t require informing the entire team. Again, this is NOT optional. It must be understood that we as a team are committed to each other and we’re not going to ”surprise” each other with changes requests. Once that is established, we need to educate the business, clients, and  stakeholders about our change control process and that they, too, must follow it.

Three Key Take-Aways:

  • If you don’t have a change control process, implement one quickly.
  • If you have one, but you’re not using the discipline to enforce it every single time a change comes through, you need to introduce that discipline to the team.
  • If you have a process and discipline, make sure that when you do the assessment all the roles are included (even if it’s one person representing the roles). Reinforce that the efforts of the QA, BA, etc.  have to be taken into consideration.

Do you have any other key best-practices for handling change control?

Alignment Through Visibility

Testing-Alignment-Through-VisibilityIn my last post, I described how a lack of true alignment could create rework for a team. Worse, a lack of alignment may be the root cause of projects that are over budget and behind schedule. So driving alignment isn’t just a nice “political” move, it actually is smart business for your organization.

Because alignment is so critical to project success, it’s important to know whether your stakeholders are truly in alignment or just appear to be aligned but are actually going in different directions. There’s an easy exercise you can use to verify true alignment or simple agreement. This exercise is based on the concept of visibility.

Before I explain this exercise, it’s important to understand the difference between visibility and transparency.

Visibility vs. Transparency

I recently had a great conversation with a colleague about the difference between visibility and transparency.

Transparency is a behavior that a team member exhibits. Leadership and stakeholders have full awareness of the team’s effort and progress because of the transparency provided by the team members. Although this is desirable, it may not provide the stakeholders visibility into the project’s future.

Visibility is the result of transparent behavior. If I have visibility, then I know what to expect in the future.

Verifying alignment through visibility

Here is a simple exercise demonstrating how you can use visibility to verify true alignment.

Lets pretend we have business stakeholders who have agreed to build a lightweight version of Microsoft Word for a mobile device.

Originally, one stakeholder, we’ll call him Michael, was concerned over the concept of “lightweight”. He believed that the version needed to be able to read any version of Word, including showing “markup” made by tracking changes. He also thought having a lightweight version of Excel released at the same time was important.

After much negotiation, the stakeholders agreed to deliver a lightweight version of Word. The technology team provided an estimate of five months for the initial working release.

To make sure everyone is on the same page, I might ask the technology team:

“Is it reasonable that within two months, we will have a prototype showing us the base app that can l open and save documents and do fundamental editing and formatting?

Would it also be reasonable that everything related to formatting, spellchecking, email integration is done by the third month?

Finally, is it reasonable that the app will be fairly complete by the end of the fourth month so we can run some quality testing? Will we be able to complete the final testing and defect fixes in the last few weeks?”

If everyone high-fives and agrees to these assumptions, then there is a high likelihood of true alignment. Everyone has clear visibility and common agreement on how we track progress to our agreed upon goals. On the other hand, if the stakeholders don’t have agreement on these assumptions, then odds are they’re not in alignment around the ultimate goals and definition of project success.

In summary:

  • Assume it’s about five months to deliver
  • By end of second month we will have initial preview of base app, file functions, core editing
  • By the end of the third month we will have spellchecking and email integration
  • By end of the fourth month we have the app fairly complete and can start testing, packaging up, etc.

However, what if the delivery team reacted differently:

They say that five months was heads down development time. The testing, packaging, and changes would be “added” to the end of the five month schedule, making it six or more months.

Then, the business stakeholders may ask: “When will I see the markup-review? Is that at the second or fourth month check-in?” Only by having clarity and a common understanding on the future visibility of the project, can we truly be on the same page and have true alignment.

A quick summary:

Another way to look at visibility: Let’s agree upon how we track expected progress. If we can’t agree on that, then we probably are NOT in alignment.

So what do you think?

Do you believe this is a problem in your world? How bad is it? I’d love to hear examples in the comments below. If you don’t have this problem, why? What do you believe you are doing right?

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

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.