Subscribe via RSS Feed

Author Archive for Bob Zimmerman

Eliminating the “Black Box Effect”

Eliminating-the-black-box1Regardless of whether you are doing iterative development or use waterfall methods, you may be struggling to get agreement on whether a delivery team is on track or falling off expectations. This blog covers techniques that can help business and technology teams agree on how to track progress of a technology project.

The Black Box: is any comparatively small, usually black, box containing a secret, mysterious, or complex mechanical or electronic device.

One of the key complaints of a pure waterfall development approach is the reality that a project may not show any results (or provide any feedback) until the software is completely finished.  In other words, the business really has no idea if the project will meet their needs or is on schedule until the software is delivered.

For example, we start a project in January.  It may take through February for initial business architecture and design to be completed.  It may take another month or two before software is actually being developed and delivered to the testing team.

The business may not get any visibility into working software for six months or more.

This is what I call the Black Box Effect. We need to find a way to eliminate this effect and have an agreed upon approach to determine whether a project is on track or not.

The benefits of an iterative approach

There are many reasons an organization may choose to move to an iterative development model such as Agile or Scrum.  One of the more important reasons is to gain more frequent feedback on whether what we are building meets the real business need.

Are you  tired of the business saying, “What did you do to me? I thought we were going to have this done.” And are you tired of hearing yourself say, “Well, I thought we were going to have THIS done!” If that’s the case, then you are obviously not in agreement and have a “visibility” problem.

Visibility isn’t a project plan!

Visibility isn’t a project plan that tracks progress. Visibility is agreeing that the business can get access to completed functionality. Visibility means the business can see how the software being developed will help them achieve their business objectives defined earlier in the process. If they can get visibility into that on a regular basis, then we can agree on whether we will be able to “high-five when the project is done.”

Not only do we need to provide the business visibility on progress, but we need to allow the business to re-evaluate their priorities based on the progress seen. Consider this a feedback loop, allowing development teams to constantly re-evaluate and tune their approach.

I use three key opportunities to provide visibility and get feedback from the business: QuickPeek, Showcase and Release.

QuickPeek

At the end of each iteration, the team should be able to show software that has been developed and completed through unit-testing. The software may not have been put through functional testing or even integration testing, but it has been completely unit tested. There may still be remaining defects.

We encourage the business to review each iteration’s results and make sure we are on track with their expectations – even if the code is not yet packaged for deployment or completely system tested. Remember, the QuickPeek  is typically informal and just to show the iteration progress.

Even in a Waterfall process, you should be able to start identifying key components being developed every two weeks that can be “viewed” by a business stakeholder for feedback.  Maybe some deliverables will take a week while others take up to three weeks.

I believe you can introduce a QuickPeek on a regular basis without too much intrusion into your current corporate process.

Showcase

When a release is going to take six or more months, there is value in planning a Showcase.  This  is a formal review of a set of features or system components.  Functional testing is typically complete and it shows complete business scenarios or processes at work.

However, it typically is not ready to be deployed like a release.

The purpose of the Showcase is to demonstrate the functionality of a complete component to a wider group of stakeholders. It is also used to celebrate progress and create a common vision around the new solution.

Even in an Agile world, you may not be deploying a release until Iteration 10 or 12.  Therefore, there probably is value in creating a Showcase around Iteration 4 and Iteration 8 to provide greater visibility and market the progress you have made.

Eliminating the Black Box creates Visibility

I hope these techniques can help even a waterfall shop create greater visibility and market the progress the team is making. Throughout the development process, it allows the business and I.T. to develop a common view of progress and decide whether adjustments need to be made to the final product.

Do you incorporate all of these techniques? If not, what are the obstacles?

April 12, 2012 | 0 comments | View Post

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.

March 27, 2012 | 0 comments | View Post

Alignment: Antidote to Rework

Alignment-Antidote-to-Rework1In my last post, I introduced the Getting Predictable℠ Best Practices and explained  how they are designed to set project teams up for success “from the start”.  These practices cover three areas: Alignment, Commitment and Visibility.

Now I am going to dive deeper into the  concept of alignment and why it is critical to reducing rework and helping any team (not just IT) meet its  expectations, each and every time.

What is Alignment?

With technology initiatives, the goal of best practices around alignment looks like this: The business stakeholders all have a common answer to the question, “What is success for this project”?  In other words, they have agreement when the team can stop and everyone can  high-five because they all got what they needed.

At the other extreme (and this is the problem we are trying to solve), we don’t want the business to say to the team: “We have a really critical schedule, so you guys start and we’ll figure it out later”.

Why is it so important to focus on aligning the business stakeholders?  Isn’t it more important to focus on aligning the technology team to the business? No it is not more important – and this answer is of huge importance!

The technology team can’t align to the business goals if the business doesn’t agree on those goals! In other words, if the business isn’t in alignment, how can a technology team align?

What are they aligning to?

More importantly, a lack of alignment on the business side means there is almost certainly rework ahead for the technology team.  As the business goes through the process of coming into alignment, the IT team needs to make constant adjustments.  Sometimes in small ways, but other times the change can be significant and involve removing or changing an entire component of the solution.

When was the last time rework got extra schedule or budget?

This blog will cover those Getting Predictable℠ Best Practices that focus on helping the business get alignment on answering this question:  “What is the definition of success for this project?”.

Alignment is a great idea, but I don’t think it can work for me

Now you  might be thinking: “I can’t get my business folks to a single meeting, let alone get them to agree!” In future posts, I will share best practices that have worked for me. They don’t all work, and they don’t apply to all situations, but I have come to rely on these simple practices to get the results I am looking for.

And there is a huge side benefit.  By helping the business come into alignment on the key objectives of a project, I end up building a new level of trust in my relationship with the business team.  This truly was a pleasant surprise.

You will find some past posts, as well as future posts that focus on key areas such as:

  • Facilitation techniques
  • Aligning the business when they are geographically distributed
  • How to align interested parties that aren’t decision makers
  • Being adaptive to change and protecting alignment
  • When a lack of alignment is ok

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.

March 7, 2012 | 2 comments | View Post

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.

February 15, 2012 | 0 comments | View Post

Facilitating A Panel Is Not So Different Than Facilitating A Requirements Session

My First AHA Moment of 2012

panel-discussion-150x150Facilitation appears to be a hot topic these days. After blogging about facilitation a few months ago, I am getting many questions about best practices and how to handle certain situations. At the bottom of this post I’ll provide links to my past articles on facilitation that should address many of these questions.

Today I want to share an AHA!

Recently I was invited to speak at an event on the topic of facilitation. One of the other presentations at that conference was a typical panel presentation.

Panels are very common at conferences; they usually have three to four people and a designated moderator who helps facilitate the discussion among the panelists and engages the audience. The session typically runs about 60 minutes.

These panels tend to be very dry (yawn)

For most panels, questions are devised ahead of time and shared with the group so they can prepare their agenda, personal messaging, and so on. I should clarify, that some panels are engaging and are very interesting. But at times, I come across a panel where each person seems to be coming from his or her personal point of view. Their views may not be clearly aligned to the question. So you get someone speaking strategically, while another may be extremely tactical or even not directly speaking to the question.

Let me magnify my point. Each member of the panel will work with the moderator to identify the question(s) they would like to be asked so they can share their viewpoint on a topic. And since three or four different panelists do this as individuals, possibly at separate times, it can be dry, without a clear set of takeaways.

I want to be clear, that there are many panel presentations that are engaging and valuable. But more often than not, I personally find them dry. As an audience member, you are trying to get a grasp of the discussion topics and understand the panelists’ points of view. However the very disparate nature of the moderator’s Q&A prevents engagement between the audience and the panelists.

Changing the dynamic of a panel…

This makes me want to try something new the next time I am invited to be a panel moderator.

I would want the audience to engage more with the panelists on stage. To get more energy, the format of the panel would have to be a little different. We are used to a panelist getting asked a question, then answering their question, followed by each of the other panelists attempting to provide answers to these preset questions which they may or may not have a valuable answer for. Then it starts all over when the next question is thrown out.

With my new approach, after the question is asked, instead of always asking all the other panelists to answer the same question, I will ask the audience members to give their perspective on the panelists’ thoughts. This would raise the engagement level of the audience with the panel.

My job as a panel facilitator would be to facilitate the rhythm of the discussion between the audience and panelists. This means I must meet with the panelists before the conference to create an agenda that would allow us (facilitator and panelists) to agree on a common objective. This would enable the panel discussion’s rhythm to flow more smoothly, be less fragmented, and not break the energy of the room.

I have already outlined in past posts, that the key to the most effective facilitators is that they monitor three things: energy, rhythm and objective of the room. The same can hold true for panel moderators (aha!)

  • Energy in the room: Everyone is engaged, participating and making constant progress toward accomplishing objectives. (For panels: Keep the audience engaged)
  • Rhythm of dialogue: The dialogue flows, but stays focused on the initial goal of the meeting. (For panels: Make sure energy does not get broken by unrelated, fragmented questions)
  • Objective of the room: Make sure the meeting stays on track and accomplishes its objective. This can be tricky since the facilitator needs to balance discussion on side topics that are helpful to the objective versus topics that derail the goal.(For panels: Make sure the questions address a common theme)

I think there would be huge value in using these fundamentals when moderating a panel discussion.

When did you last attend a panel that really impressed you and what was so unique about it?

What are your thoughts about changing the dynamic of a panel presentation?

You can find more details on facilitation best practices in my past blog posts here:

They are some of the fundamentals that I present in my regular class on Facilitation Best Practices.

January 18, 2012 | 0 comments | View Post

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.

November 16, 2011 | 2 comments | View Post

The Role Call: A New Practice to Set Your Team Up for Success

The-Role-Call-ChecklistLast post I wrote about how often we begin a project from a disadvantage right from the start. Usually it’s because the team doesn’t have the resources or the commitments it needs from outside of the team.

In this post, I want to talk about a new best practice I am experimenting with. This practice is  designed to help set teams up for success by focusing on the project team resources. I call this best practice: The Role Call Checklist.

Key Roles On a Project

First I need to  explain the common thinking on key project roles: Specifically, every project is made up of 4 key roles. In no particular order, these roles are:

  • The Architect: This is the person responsible for the technical solution. For example, “does it work or do you get 404 or blue screens of pain”?

 

If the final application doesn’t technically work, or if it doesn’t meet a non-functional requirement, such as scale, then the Architect is accountable. I am not going to follow up with the Project Manager. It’s the Architect’s responsibility.

  • The Senior Business Analyst: This role is about  understanding what business problem this project addresses and, from a business point of view, what is success. Business Analysts are the proxy for our business users.

 

If the final solution works technically, but doesn’t do what the business needs, and doesn’t allow the business to achieve their goals, then the Senior Business Analyst is responsible.

  • The Senior Quality Analyst: QAs are responsible for the quality of the solution. Before everyone jumps on me, I don’t want to get into the discussion of exactly what the QA role is and how encompassing it is. I am a true believer that the QA role is larger than a testing organization. Their job is not to simply test and place a sticker on the software saying “Inspected by #12”.

But for this post, I hold the Senior Quality Analyst accountable to identify what quality the system holds.  What are the defects and is the system compliant with the intent? If the system technically works, and if it was designed to meet the business needs, then the Senior Quality Analyst is accountable to say whether it is ready to ship.

Finally,

  • The Project Manager: The PM is responsible for overall transparency.  This person needs to have an accurate picture of where we are in relation to schedule, budget and meeting Business Objectives. Further, they are accountable to serve the team by helping to identify and, more importantly, facilitate removing obstacles that can prevent the team from being successful. They are the manager.

Although I believe every project, small or large, has the need for these four roles, they don’t necessarily need to be four separate individuals. On smaller projects, you may have a single individual playing the Project Manager and Business Analyst role.  Or you may have the Business Analyst playing a Quality Analyst role. It depends on your culture and the strengths of your team members.

But the need to define:

–        What you are building,

–        How you are building it,

–        Whether you built it properly, and

–        How you’re managing the process

is required on every project. When a smaller team doesn’t believe they need each of these roles, it can create a gap to successfully delivering a solution.

And this brings me to the new best practice I am experimenting with:

The Role Call Checklist

I create a mini-checklist for each these roles. Under each role, I write what the role is accountable for. While there probably will be a common list of  responsibilities across many of our checklists, each role will also have some unique views.

If you are assigned a new project, I recommend creating this checklist to determine who is playing each of these roles.  On a smaller project, you may have one person playing two or three roles.  On a larger project, you’ll want to  identify the key owner of each role.

Then, I recommend that you meet with your team and make sure you are all in agreement as to who is doing what, and what the team is relying on each person for. I believe this small exercise can help a team start more successfully, especially when resources are scarce.

If you have a checklist, I would love to hear from you and find out what works and what doesn’t.  Does it make a difference?  Are you willing to share yours?  Feel free to add a comment below.

October 19, 2011 | 0 comments | View Post

Are You Holding Back Your Team’s Success?

Damaged WallRecently, I hooked up with a friend and decided to do a 3-day hike on the Appalachian Trail.  As part of our preparation, we decided to try a day-hike in a State Park near our homes. We took this trial quite seriously and even planned how to mentally and physically prepare for the day hike.  I won’t bore you with the details, but the day we set out for the hike, we were pretty psyched.

We did 8+ hours on the trail, walking up and down paths that burned our legs by the end of the day. In the last hour or so, when were truly coming to our “wall of tolerance”, we kept repeating to each other how fortunate we were for all the planning. Had we not trained for this or lacked  the right supplies, we would have never lasted the day. Without a doubt, doing the day hike before setting out on our 3-day hike out east was the smart thing to do.

We focused on setting ourselves up for success.  And even with all the planning, we still learned a lot about what to do differently on our next day hike.

Learning From the Hike…

I can only imagine how painful that day would have been if we didn’t work our way up to walking an entire day of 13+ miles.  Or what would have happened  if we only had half our water ration (we used it all).  It would have been one embarrassing, failure of a hike.

This is a far more common scenario than any of us realize. When we start a new project, we typically overlook fundamental / key things that would set us up for success.  We may actually be holding our team back from the start.  And because of that, our team  may be digging out from this “team debt” for the majority, if not all, of the project.

Hold Up There

If you don’t agree, let me  give you just two common scenarios  that prove my point:

  • You  are starting a project. The  team is staffed and eager to move forward. The technical team is building out the environment and frameworks.  The Business Analysts are ready to collect and refine requirements, but are struggling to get the needed time and commitment from the business.

This not only causes churn for the BAs, but typically squeezes the schedule during the initial coding activities, with incomplete requirements and test plans.

  • Another example: You  are staffing up a project quickly so you can hit a set of aggressive dates for the business.  In doing so, you need to procure development environments and machines for all of the developers. However, due to an overworked infrastructure team, or worse, due to corporate processes, a third of the team may be without development hardware and tools while they wait for their stuff.

While they find other activities to do while they wait, this literally amounts to two or three weeks that could have been spent on actual deliverables.

These are just two common examples. You could probably start listing off a couple more.

What Are They Thinking?

So when this happens, what is management thinking? Are they intentionally setting a team up with an obstacle? Do they simply not care and assume we can adapt?

I believe that in most cases, management simply doesn’t realize that the team is being put into this position and the cost is more than a slow ramp-up to the project. I, myself, have asked teams to “see if they could work around some obstacles”, clearly not realizing the pain I may be introducing, not just short term, but to the long term success of the team.

So What Are We To Do?

I think one of the most basic things we can do in these situations, is to be vocal.  Share your clear and honest explanation of what the cost and impact is.  It is important to be accurate and not embellish or magnify the challenges.

For example, let’s say you have a project starting and are scheduled to collect requirements for the first deliverables during the week of 11/01.  Your  goal is to have the requirements and test plans completed by 11/15 so the developers can begin development.

If the business stakeholders are not available as needed the week of 11/01, I think it’s important to point out that development may not start until 11/22.  This is because the test plans won’t be complete and the requirements won’t be clear enough (the normal clarification won’t have happened).

If you can clearly show the cause and effect, management should take ownership of the cost and impact of these situations. If we can show them the cost in terms of dollars or in terms of schedule, then you have the best shot of setting your team up for success and getting management to own the challenges.

What do you think?  Have you found other approaches to help set teams up for success?

October 4, 2011 | 0 comments | View Post

IT as Great Facilitators Part 4

What Great Facilitators Know About Estimating

IT-Great-Facilitator-4Last post, I shared an exercise that helped teams understand how to develop a plan that is manageable and achievable. I call this “Commitment Based Estimation”.  Now, I will show how great facilitators can play a role in making their teams super confident about their estimates.

Who Should Facilitate an Estimation Session?

Before we talk about how to be effective at facilitating estimation sessions,  I’m going to discuss how to select the best person to facilitate these sessions.

I typically find that the team-lead drives estimation sessions. Project Managers and Architects are also fairly popular in this role. The key, however, is to find a person who can allow the team to own the estimate.

When a Project Manager leads the estimation, they usually drive a team to develop estimates that reflect the project plan. Once the Project Manager starts imposing schedules, or challenges the team to constantly optimize an estimate, then the team won’t feel ownership. This is not how to get a Commitment Based Estimate.

Similarly, when an architect drives the estimate, they typically assume a technical frame of reference and try to help the team understand the mechanics of the estimation. If they impose their vision for the complexity of certain tasks, once again, the team won’t feel ownership.

So who makes the best facilitator for estimation sessions? I’d say look for a person who is:

  • Part of the team and has skin in the game
  • Already a respected leader and trusted by the team not to impose their personal views
  • Is experienced in helping teams balance risks, contingencies and dependencies

One Rule You Should Never Break

There is one rule the facilitator must never break: Allow the team to come up with estimates they believe in. Unless the team is very junior or new to estimating, every team needs the freedom to come up with their own estimates. If the team asks for two weeks, never impose a shorter schedule and tell them to get the job done in one week.

Now, you may be thinking: Does this mean I can never challenge a team? It does not. What is does mean is that as a good facilitator, you ask the right questions and help them share and test their assumptions.

For example, ask the team: “What would you need to get this done in a week?” or “How much can you get done in a week?” By asking the right questions, the scope may get reduced. Now, you get the deliverable within a week because the estimation was not imposed on them. Again, the facilitator does not want to undermine the ability of the team to own the estimate.

Other Things Good Facilitators Can Do:

Some of the other approaches that have helped me personally manage some very strong groups include:

  • Make sure the team does not give an estimate that is simply unrealistic.  I talked about this in a past blog called “Attitude of Estimation”.  As a facilitator, you want to encourage the team to come up with an estimate that is workable.
  • Ask questions and create assumptions to make the team think of scenarios that might happen. This helps the team create more accurate estimates.
  • Make sure everyone has a voice. Business Analysts need to be able to articulate the business needs and clarify what is being delivered.  Project Managers can offer perspective on dependencies and resource availability.  The QA team needs to test not only to see if something works, but also to see if the product is in compliance with business needs. Developers, Architects, and the database team also need to weigh in.  Too many times an estimate does not include a full set of voices and results in inaccurate estimates and mediocre functionality.

Have you ever been in an estimation session where the facilitator was more of a hindrance than a help?

I hope you have enjoyed my 4-part series on facilitation. If you missed them, here are the links:
IT as Great Facilitators Part 1
IT as Great Facilitators Part 2
IT as Great Facilitators Part 3

In my opinion, there are way too many people who take the facilitator role for granted.

I think there are some jobs that are too important to perform any less than perfectly. Facilitation is one of them.  A poor facilitator can break the spirit of a super talented team while a great facilitator can lead a good team to surprise itself on what it is capable of.

September 22, 2011 | 3 comments | View Post

IT as Great Facilitators Part 3

Commitment Based Estimation

IT-as-Great-Facilitators-Part-3I want to tie together two concepts I have blogged about in the past few months. Specifically, how proper facilitation can help a team confidently develop a plan that is realistic and manageable.  This is what I call Commitment Based Estimation.  As a quick review, Commitment Based Estimation is an estimation approach that helps a team:

  • Develop estimates they genuinely believe are achievable
  • Feel ownership for their estimates
  • Treat these estimates as commitments and therefore honor them by managing to their plan

You can find my previous posts on this topic here:

Experiencing Why Commitment Based Estimation Works

I’ve used the following facilitation exercise to help teams understand some of the flaws with our typical approach to estimation.  This activity also demonstrates why Commitment Based Estimation can lead to much higher quality results.

I always do this 2-part estimation exercise in person and always with a group of people. Important: If you do this with others, be sure to state the following rules:

  1. You cannot ask any questions. Do your best with the information I give you.
  2. Write down your answer. This is important (especially when doing this in groups).
  3. You cannot collaborate or look at your co-worker’s  answers.

I’d like you to choose a shopping mall or large shopping center that is a typical weekend shopping destination for folks near your office.  The key is that it shouldn’t be across the street from your office, but requires a planned trip to get to.  For example, where I work, there is a shopping center called Oakbrook Mall, which is about four miles from my office.

Now here is the first step.  I’d like you to personally estimate how long it will take to leave your office, go to the shopping center, and find a store that carries designer sunglasses.  Then, purchase a pair of glasses with mirrored lenses for your spouse or other family member.  Then drive back to your office and drop off the glasses.  Oh … and one other thing… On your way  back to the office, please pick up an ink cartridge for your inkjet printer.

Now, I challenge everyone to come up with the estimate above. They each get about 90 seconds to come up with their answers.

The First Readout…

I then go around the room and ask everyone to read exactly what they wrote down as their estimate. It is important they use the exact words they wrote down. 60 minutes is not the same as one hour.

If you do this with a group, you will get all different answers. Typically you will get:

  • Someone who is  optimistic and says a very short time. From my office, they might say 30 minutes.
  • A  few folks who give a pretty precise estimate. For example 53 minutes, or one hour and 12 minutes.
  • Someone who  might be swagging it at one hour or “an hour and a half”.

That Was the Setup. So Now You Change the Game…

After everyone has done their readouts, I then say “great job” and explain that I want them to estimate again. However, this time  they have something to lose. I pretend that I am giving away an iPad or some other prize to the three folks who provide actual estimates.

So, I want them to redo their estimates. Knowing there is a prize at stake, they now have something to lose!

And Then the Fun Begins…

I now give the group another 90 seconds to redo their estimates.

If you actually created an estimate while reading along, I’d like you to take the opportunity to make it “more accurate”.  Pretend you could win a real iPad if you create an estimate that you can deliver on.

I then go around the room and ask everyone to give both estimates.  So again, here are some typical results during the second readout:

  • The person who was optimistic at 30 minutes says: My original estimate was 30 minutes and my new estimate is 42 minutes.
  • The folks with the precise estimates of 53 minutes either stay the same, or they may go up a little to 61 minutes.
  • (This baffles me.) There’s always someone that will take their estimate and actually lower it. They may go from 80 minutes down to 70.
  • And every once in a while someone “pads” their estimate and says “one full day”.

Seriously – the Lessons We Can Learn …

This seems like a hokey exercise. Yes – I am a hokey person 🙂 .  But let’s look at the real takeaways:

  1. When we did our first estimate, we didn’t take it seriously. The goal of the entire activity is to realize that if we have something at stake, we will actually estimate differently, and try to come up with an estimate we can confidently deliver on.So when our project teams are estimating, are they approaching this as the first go around?  Are they saying “You want an estimate? 53 minutes.”  Or do they understand there is something at stake?  They should re-think and verify that they can deliver on their estimate. Do they understand there is much more than an iPad at stake?
  2. We assume that an estimate should be as low an estimate as possible, even if it creates risk to delivery.When we estimate, are we so afraid of estimating for real world contingency and risk that we always estimate optimistically?  We probably shouldn’t pad to a full day, but we aren’t asked to make the estimate the “best case scenario” either.It should be an estimate that we all believe is achievable and can be managed to!
  3. When I do this in group, everyone wants to ask questions.  Is there construction?  What time of day are they going? Do they know what store has the glasses?  But as part of the rules, I say no questions are allowed.When they do this exercise, they can even be frustrated that they are being asked to create an estimate without knowing these answers. They think “How am I supposed to estimate this”?And this is exactly what happens in real life with our project teams!  It is the nature of our world that teams will always have some questions that can be answered and many others that cannot be answered. Yet, we still ask them for estimates that we can plan and execute against.

Commitment Based Estimating

Commitment Based Estimating is about helping a team deal with all three of these challenges. In my next post, I will talk about how proper facilitation can help a team deal with these challenges and deliver a Commitment Based Estimate that everyone believes in and the team can manage to.

Can you think of any situations where it would have been worthwhile to try this exercise before delivering an estimate?

September 8, 2011 | 1 comment | View Post
« Previous Page — Next Page »