Subscribe via RSS Feed

Category: Defining Success

Is Your Software Development Team Set Up for Failure?

Obstacle - Man Jumping Over Word on ArrowI talk to CIOs all the time and I can tell you that there is one common concern keeping them up at night:  Am I getting the best RPM out of my team? Often the answer is no.

Unfortunately, many of the teams I’ve worked with are continually frustrated because they truly, legitimately feel they are being set up for failure. They’re tired of being told they’re late, spending too much money, or missing the boat when it comes to getting the business want it really needs.

Throughout my career, I’ve heard this question from my peers, direct reports and senior executives:  Who or what can we change to fix our team? If these concerns are on your mind, I highly recommend taking a look at my white paper: “Doing More with Less – Best Practices for Processes, People and Metrics.”

This whitepaper will help you identify opportunities for optimization based on your specific organization, business situation and culture. Some of the concerns I address:

  • Is your methodology getting predictable, repeatable results?
  • Do you have legacy practices and tools that actually hinder performance?
  • Are the right “heads” in the right “hats”?
  • Is everyone on the same page as to who owns the success criteria for projects?
  • Are you tracking the things that make a difference to the business?
  • Are metrics visible and “common” across IT and business?

This white paper will get you started in one of the most critical roles you have: Removing obstacles.  If you don’t support your team in removing the obstacles that prevent it from delivering, you are setting your team up for inefficient and unpredictable results.

Please take a look at this white paper as soon as you can and feel free to post your comments right here.

Geneca Whitepaper – Doing More with Less

You Guys Start, We’ll Figure This Out Later

Ready Set GoWe’ve all experienced a project that is kicked off just a bit sooner than maybe it should. You know this because you hear those infamous words:

“You Guys Start,
We’ll Figure This Out Later.”

Consider this simple phrase a warning sign that your project is in danger before you even start. The business team is still trying to figure out what they need. Yeah, they know their problem is clear but the solution is anything but.

So what’s behind this all too familiar call for help?
Lack of Alignment.

What the business is really saying:

“You Guys Start and We’ll Get Aligned. Right Now We Can’t Agree.”

This lack of alignment is almost always due to the business stakeholders’ struggling to determine and agree on what “success” is. This can apply to a product implementation, customer software development or even a change in business processes.

Some disagreements can be on the large scale:

Should our first release of tax planning software only focus on Federal tax strategies or must it support State tax planning too? If it should, which State? All 50? Isn’t that going to take forever?

Should we develop a full suite of open source Office type products including a word processor, spreadsheet, Powerpoint like tool? Or should we simply focus on our core offering, the presentation tools?

Some disagreements appear less strategic:

Does the solution have to support our customers in four countries and be localized in six languages? Or can the first release simply support our current client base?

Should our solution include a Spellchecker for the medical terms that we will collect in our survey tool?

“You Guys Start, We’ll Figure This Out Later” = Less Than Successful Project

In spite of this warning, the project needs to start. So we begin our planning and whenever possible, hedge our design to accommodate change. But, in the end, how likely is it that we deliver what they, the un-aligned business stakeholders, fuzzily define as success?

More often than not, they never get aligned. And if a new business person gets involved, who knows what their view of success is. At the end of the day, we are responsible for a potential “less than successful project”. Hmmm – they may even call it a failure!

And this shouldn’t surprise us! In fact, if you hear the words “You guys start…”, that should be a predictive flag that you may be setup for failure.

The message is clear: The Business needs to own the risk of having an I.T. team start without alignment among the Business. And the Business along with I.T., needs to jointly own and collaborate on how I.T. will re-plan once the business has completed their work by finally agreeing on what is project “success”.

What About Agile?

When I share these ideas with colleagues, I typically get two reactions. The first includes smirks and smiles saying: “Yep – we’ve heard that and you are right, it is painful.”

The second reaction comes as a challenge: “Wait – isn’t that what Iterative development is all about? The business can plan and change direction with every iteration?”

The assumption is that Iterative methodologies such as Scrum or Agile, can be an effective way to solve nonalignment situations. They break up a project into small durations (iterations) that focus on specific feature sets. An iteration may be as small as a week, but may be defined as large as four weeks. (You’d be surprised at how much energy this last point generates.)

This is often considered a safe/natural solution because at the beginning of each iteration, the business will look at the list of everything they want and define the target features they would like the team to work on for the next iteration(s). This re-planning allows the business to change its mind and adapt based on feedback and potentially changing business conditions.

An Iterative process doesn’t resolve alignment issues!

But we still have a problem here: The Business Stakeholder who kicks off each iteration is now accountable to determine what “success” is for that iteration. If they aren’t aligned with the original/other stakeholders, then they are actually steering the ship off-course. And there is NO visibility. The rest of the stakeholders may not even know what decisions and tradeoffs have been made within an iteration planning meeting.

But wait Bob! When we do an Agile project, we always have all stakeholders in the loop about which features were completed and what will be planned for the next iteration!

And to that I say: You are not the norm! So congrats!

When most organizations embrace Agile, they are focused on the core I.T. team, planning and execution. They don’t have a model for how this changes the behavior of the business stakeholders in their planning and management of initiatives.

True, we tell the business folks we want them in the room with us, giving us quick feedback, etc. But what we often don’t do is explain to them that this level of feedback requires them to constantly re-baseline what features are “in and out” based on their goals and budgets. There is no formal process for shifting this ownership over to the business.

So what’s the point?
ITERATIVE ALIGNMENT

The fact is that more often than not, a project will be started after hearing: “You Guys Start, We’ll Figure This Out Later”. It is the nature of business and politics. In fact, as I illustrated above, our iterative processes can almost “enable” a lack of alignment.

It’s important for us to set goals for the business to do regular “alignment-check-in”. We need to make sure the business owns and is accountable for understanding what they are asking for, and what changes have been made.

We should strive to eliminate the surprises at the end of a project where a business stakeholder asks:

  • Where did this feature come from? or
  • Why is this functionality missing?

Even if we followed the requirements to the letter.

So what do you think? Do you disagree? If you agree, who do you think should be accountable for managing this within your team? Within the business?

The Attitude of Estimation

The-Attitude-of-EstimationOver the past three or four blog posts, I tried to challenge our thinking on estimation by sharing some specific ideas on why padding an estimate is evil or how a SWAG can actually be fairly accurate.

Now I want to take a step back and share the biggest obstacle any organization has to getting consistent estimates. By that I mean estimates that drive confidence for the team and it’s stakeholders. That obstacle is our attitude towards estimates.

To clearly share what I mean by our attitude, let me share a typical estimation experience:

Experiencing the Attitudes of Estimation…

I am working with a new team and walking them through some standard use cases or agile stories. I present the first feature, the team evaluates it, and give me their initial estimates.

One person on our team, let’s call her Ann, quickly throws out “This should be about two days”.  Another senior member of the team, let’s call him Jerry, says: “I can’t imagine that taking more than a couple of hours”.

I ask Ann, “Why do you think this is two days”? She responds: “Well if I say a day and there are defects etc, it’s going to take longer. The truth is I don’t know whether this is one day or three days – but this is only an estimate. No matter what I say it’s going to be off, and you’ll be unhappy”.

After defending myself and saying “That’s not true, yada yada yada”, I then turn to Jerry asking why he thinks this is only a couple of hours. He responds, “How hard can this one be? It’s a straight forward screen. I just have to get a new table built with the reference codes and we are good to go. I don’t see any challenges”.

One of Jerry’s teammates asks: “Isn’t it going to take some time to download the reference codes, clean them up and get them in the table? And shouldn’t we create some quick automated tests to make sure this works?” Jerry pauses and says: “Well I guess. If you want to include all that then I need a full half day”.

Finally Ann jumps in and shares: “If you ask me, I think you should estimate a full day. We’re going to need the QA team to sign off and by the time you do any adjustments, it might take you all day”.

Jerry doesn’t necessarily agree, but the team agrees it’s better to be safe then be sorry.

Why These Attitudes Make Sense…

I regularly find both attitudes on the same team across companies, sectors and experience levels. I understand both approaches. I can defend them!

Ann is right. No matter what we estimate, it’s going to be wrong. That is why we are estimating and not “predicting”. In fact, I’d even argue “weather forecasting” should be called “weather estimating”. Forecasting suggests we are truly predicting. Estimation suggests based on what we know and the models we are using, here is our best guess.

And Jerry also isn’t wrong in saying he knows that it will take two hours. He genuinely believes for the feature at hand, he can get this out quickly. However, the team quickly reminds him that there are other “tasks” and “team members” that need to be included in his estimate.

Commitment Based Estimates

Having different attitudes and approaches to estimation is a clear obstacle to getting consistent estimates that can be managed and adjusted. To remove this obstacle, I suggest having a standard approach or attitude to estimation. I call this approach: Commitment Based Estimates.

When asking for estimates, I want the team to understand, I am not asking for the smallest, leanest, quickest estimate for each task. If I did, this optimistic plan would simply be impossible to deliver on. It won’t take one small thing into account: LIFE.

I also don’t want them to pad estimates and not be realistic.

So I ask them to think about it from the point of view of “commitments”. When can you commit that this feature will be “done/done/done”? When do you believe it will be ready for deployment to our integration test environment?

I then clarify: That means you have to take into consideration any “clarification” of requirements, obtaining resources such as a tables, test data, web services, tools, conversion scripts, documentation and so forth. It also means you have done your testing and are comfortable that this actually works. You are proud of the result.

In our previous example, the team compromised and said this would take a full day to finish our feature. I might test this by asking the team: “Would you bet your paycheck on this? In other words, are you truly committing to that one day estimate”?

In the real word, if we are working on something that we said takes a day, and it ends up taking an extra 45 minutes, we would typically do what it takes to get it done on schedule. That is the nature of development teams. We truly want to deliver on expectations if “we own them”.

I could write another page or two on Commitment Based Estimation, but I won’t (yay)! I will leave you with these other thoughts:

  • Never force an estimate on the team. If you are doing Commitment Based Estimation, the team needs to feel full ownership for the creation and development of their commitment.
  • I highly recommend all estimates be in ½ day increments. More specifically, NOT in hours. If I say I am going to be done in 6.5 hours, am I actually going to get another .5 or 1.5 hours worth of work on my next task done? Stick with ½ day, full day,  three days or five days etc…
  • If your estimate is longer than a week or so, I’d challenge the team to split the work into two tasks and estimate them separately. (There may be some exceptions to this one.)

The Goal: Consistency

Regardless of whether you agree with Commitment Based Estimates, it’s important to get the team to have a common attitude to estimating as much as a common approach. I hope you give Commitment Based Estimating a try. I have found a great deal of success with it.

I’d be very interested in hearing your experiences with “attitudes” towards estimation and why you believe this approach will or will not work with your team. Please leave your comments below!

As always, please feel free to share this post with anyone you think might benefit.

What Abbott & Costello Can Teach Us About Software Requirements

Whos-On-FirstGrowing up, I used to love watching old black and white comedies, particularly Abbott & Costello.  If you’ve never seen their classic “Who’s on First”, you can find it right here on YouTube.  Feel free to watch it now (but be sure to come back)!

Briefly, this comedy skit is about Abbott explaining to Costello the names of the players on their baseball team.  The names of the players include “Who” playing 1st base, “What” playing 2nd base and “I Don’t Know” playing 3rd base.  Costello wants to know what the players’ names are, so he would ask “Who’s playing first base?” and Abbott would proudly respond “Exactly”.  A frustrated Costello asks “What is the name of the person on first base” and now Costello would reply “No, he plays second”.

If you have never heard the routine, you must listen to it to appreciate it. The link above should help. But I digress.

“Who’s on First” can teach us a great deal about the pitfalls of collecting requirements:

We can have two business users reviewing the same requirements document, each thinking it says something very different. It gets worse. In the real world of requirements, this confusion isn’t limited to two individuals. It spans the entire team, including the business analysts, testing team and developers.

The obvious difference between the “Who’s on First” routine and real life requirements, is that Abbott & Costello know they are having a communication problem.

In the real world, the situation is actually much more challenging.

The “Spellchecker”

Let me share with you an actual “Who’s on First” example that happens almost every time we collect requirements.  I call this the “Spellchecker” (and this is totally fiction, made up for illustrating my point).

Let’s pretend we need to add Spellchecker capability to our mobile application. We send out an RFP to various firms. In this example let’s say we send it out to Apple and Microsoft.

Apple responds and says they need two people working for two weeks.
Microsoft responds that they need four people working for six weeks.

We wonder: how does one company’s estimate result in four person-weeks while another is twenty-four person-weeks?  Did Microsoft pad their estimate? Or did Apple simply not spend the right energy on estimating and they pulled a number out of the air?

So we ask Apple: “What are the two people going to do for two weeks”? They respond that they will build two screens and one engine. The two screens will include the screen that shows you replacement words and a confirmation screen.  The engine is the actual “Spellchecker”.

Seems reasonable.

Then, we ask Microsoft: “What are four people going to do for six weeks”? They respond that they will be working on eleven screens and three engines and possibly some APIs.

Hmmm. We pause and ask: What are these eleven screens going to be used for? They explain the same two screens and engine that Apple discussed.

But they also have screens that allow you to add and maintain a list of “custom words” for your personal dictionary.  Further, they have screens that allow you to plug in a proprietary dictionary such as a medical dictionary or a special language.  That is how they got to eleven screens.

WOW! I never thought of that detail. Now I have to think of which version of the “Spellchecker” I really want.

If I want the two-screen version, I have to ask Microsoft to change their assumptions and re-estimate.  If I want the eleven-screen version, I have to provide the clarity to Apple and ask for their re-estimate. Most likely, I may want something in between. Maybe a seven screen version. I want the “custom dictionary of personal words, but NOT the proprietary dictionaries”. So I clarify and ask them both to submit a re-estimate.

Unlike Abbott & Costello who knew they weren’t communicating, in  the real world, we usually don’t catch our “Spellcheckers”. The BAs write up the requirements and the developers deliver the code.  We all think:  How difficult can it be to understand? After all, the business folks said they just want a Spellchecker! How much more straightforward can you get?

And later, when we deliver a solution that missed the point, the business will hold the BA and developer accountable! I mean it’s as simple as “Who’s on First”!

Taking the First Step

After sharing the “Spellchecker” story with the teams I work with, we actually use the word “Spellchecker” in our every day conversations to help uncover ambiguities and assumptions. It’s sort of a “keyword” around here.

Say we are discussing how we  can’t put the next release of our software into production until we fix all of the defects that our top executive just finished screaming at us about. The developers estimate that this can take two to three months.

Our manager responds that we are estimating out of fear and these defects can be squashed in weeks. There is no way he is telling the executives that they have to wait another “three months”!

Then, someone pop-ups in the heat of this conversation and says:

Time-out.  Do we have a “Spellchecker”? When you say fix “All the Defects”, we see there are over 50 defects in the system and we can’t imagine fixing all of those with four developers in a matter of two weeks.

Our manager responds:

50? No way!  We only need the Severity 1 defects fixed. There are only four of those defects.

And the team responds:

That makes a big difference. Yes we should be able to get that done in a couple of weeks. But are you sure that the Executives agree to only work on the Severity 1 defects?  It’s a Spellchecker to them too!

The Benefit of Acknowledging Spellcheckers

Not only do the teams I work with use the word Spellchecker to call out ambiguities, I have clients that have adopted this practice, calling out situations where they question whether  “are we really talking about the same thing”. (In fact, the spellchecker concept is so useful, even my family has adopted using it).

There will always be areas that slip in between the cracks. You can’t catch every Spellchecker. However, the real benefit of acknowledging Spellcheckers is the fact that everyone acknowledges that unintentional Spellcheckers, not individuals, can be obstacles to a team’s effectiveness.

More important, Spellcheckers often point to a two-sided misunderstanding.  Many times, when you uncover a spellchecker in requirements, the business person will say: I didn’t even think about that. I am not sure what I meant.

I’ll add one more example: When a business user identifies a defect in the software we delivered, we argue that this is an enhancement and not a defect. This is usually a Spellchecker in action and we are both right (or wrong)!

Now, Who Did You Say Is On First?

My suggestion is to introduce the concept of Spellcheckers to your team and ask everyone to speak up when they see Spellcheckers.  Share this with your business folks, management, and everyone else involved on the project. When you identify a Spellchecker, everyone can agree that no individual is at fault. It is simply a challenge in every day communication.

I’ll leave you with a final link.  I recently came across another short video that is a modern day technical version of “Who’s on First”.  I hope you enjoy this as much as I did. I especially like the punch line at the end.

Please comment and let me know about how Spellcheckers create confusion in your world and any other insights on the topic.

If you think others in your network or organization would benefit from learning about Spellcheckers, feel free to share this post using the tools below.

Photo Credit: Purple Slog

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.

Estimating Without Fear: How To Do Away With Padding and Still Come Out Looking Like a Hero

Estimate-Without-FearWhen your team puts together an estimate, does it command a sense of confidence, trust  and respect from those reviewing the estimate? Or, is it assumed that  your estimate typically  is padded and may be off-by-an-order-of-magnitude?

 

Do people believe, that even though some changes will occur due to dependencies out of your control, your estimate is still reasonable and something the organization can  manage to?

Or, do they say that it would be great to hit that date, but still  challenge your assumptions and believe you’re really going to miss it?

I am sure that most of us will answer that “it depends”. It depends on the size of the project, the complexity, the individual asked (Harry never trusts our estimates), and so on.

So let me ask you to think of this from a different perspective.

  • Does your immediate management, your boss, typically have confidence in your team’s estimate?
  • Do your business sponsors and senior executives typically have confidence in your team’s estimates?
  • And for the most telling question of all: Do all of the members of your team who participated in creating the estimate, typically have confidence in the estimate and the ability to manage to it?

I am always surprised at how inconsistent these questions are answered, especially the last question.

In this post, I want to discuss the estimating activity that does the most damage in terms of  building  credibility and confidence, as well as  our  ability to predictably meet expectations.

Padding Your Estimate!

Padding an estimate is as common place as speeding over the posted speed limit. Sure, there are a few folks who typically follow the posted speed limit, but most of us realize that when they posted the 55 mph limit, that really is “highway speak” for 65 mph.  We pad that speed limit too!  But NOT for the same reason.

From my experience, padding an estimate is done out of fear.

We pad an estimate for fear of the unknown.

“I have worked with Jerry often enough to know that there is a chance he will want to tweak the report layout.  Also, even though he says keep it simple, he’s going to change his mind and will want to add features like exporting to Excel and PDF. If I pad this estimate, I’ll have enough time to give him what he really wants and be a hero by coming in on schedule and on budget. Hmmmm should I pad it by 25%, 100% or more? Hmmm?”

We also pad an estimate for fear of the known.

“I am going to need some new tables from the DBA team. I’m also going to need the backend services team to add some features to two web services.  This should only take a day or two, but I know that the process and wait time will take at least a week or two.  I should pad my estimate to allow for that, so I am not blamed if they take longer to deliver their changes.  I don’t want to be blamed. “

Remove the Fear Factor With Contingency Estimating

Your  fear is real. In fact, the truth is that many times, the fears become reality and we need the extra time. This is where  Contingency Estimating comes in.

The one consistent theme that padding an estimate has is a base and a pad. I think it will take two days (the base estimate), but because they always change their minds, this will take a full week to deliver (the pad).

With Contingency Estimating, you actually want to “advertise” and “magnify” your pad!  This is counter-intuitive, but you want to describe your estimate in the following way:

We believe this will take two  days.  We also believe, from experience, that we will take time during the review and find changes and enhancements. This happens every time and since Joe will want these changes, we believe we should plan on additional three  days of contingency time to let Joe volleyball back and forth so we can deliver this. So my estimate is two days to get it initially done, and three  days to let Joe modify,  enhance and get this done/done/done.

Now management can understand that if they want to reduce your five day estimate, they need to work with Joe – not you – on how to eliminate the rework or agree that the extra  three  days is  needed estimate to “get this right”.  The key is Joe owns the contingency time! And you have been transparent about what is driving your estimate.

Just as important, Joe knows that we have planned to allow for three days of review and enhancements and that he needs to have some ownership in time-boxing his review in that time-frame and schedule.

Here is another example:

We believe building this functionality will take about  one week. We can manage our part to the one week. However, we have to wait on the ERP team to modify their web services to handle the changes.  This typically should take three  days, however, they are so backed up, they typically take up to two weeks to complete the work and remove any defects. So my estimate is one  week and three days to do the core work.  However, I am adding seven business days as contingency time for integration, testing and making sure the ERP team and us are talking the same language.

Again, management can now understand the cost of the team-to-team communication and integration.  It doesn’t necessarily mean there is an ERP team problem! In fact, the challenge may be with your team and their ability to pro-actively manage in an integrated and distributed environment.

The truth is, it’s irrelevant “why” this happens when you build the estimate. It’s important to share the contingency time and then to tackle how to optimize later. This will build more confidence than “Padding” your estimate.

In Summary…

I hope you find this a reasonable approach to clarifying  for your management and team members what drives  your estimates and what part of your estimate is contingency planning for the “real world” challenges you deal with day to day.

Taking it a step further, I also hope this approach allows everyone to come to the table and begin the process of identifying areas that the teams can start managing better and  improve the actual time it takes to complete work. This would be done by first identifying contingency estimates and then addressing potential waste in the organization.

If you have a different opinion, I’d love to hear it. Please leave a comment and let us know!

The Biggest Management Lie You’ll Ever Hear: “I Won’t Hold You To It”

Wont-Hold-You-To-ItI have to be honest on this one.  Not only have I been on the receiving end of this, but I am guilty of saying these words as well:

“I need a high-level estimate.  I won’t hold you to it. I know you typically need more time to create an estimate, but I am looking for an order-of-magnitude estimate. Can you get me something by tomorrow? Again, I won’t hold you to it. I know you need to do a full estimation process to give me the real number. I’m just looking for a swag.”

And then, at some point  in the future, management gets the  real estimate. It is almost always higher (sometimes double) and management (myself included) can’t understand how it got that way.   How can you go from $100k to $125 or $150k?   Or from two months to almost four months?

And, inevitably,  the creator of the swag estimate is asked,  “So what would it take to get down to the original estimate?”

So What is Management Really Thinking?

When you are the recipient of the line: “I won’t hold you to it”, the  first question you have to ask yourself is:  What was management thinking?  When management asks us to provide a high-level estimate, what do they really need that number for? It seems they were saying, don’t worry about being inaccurate or way off … I won’t hold it against you! But this isn’t rational.

Management is Trying to Make a Business Decision!

They are going to use that number for decisions. Decisions at their level! Decisions that may determine:

  • Go/no-go on a project, or
  • Do I need to plan for more budget and if so, what kind of dollars are we thinking of, or
  • Do I need to request more staffing or can I give away resources, etc.

These are typically higher-level decisions.  That means the estimates they are asking for are actually as important as any other combination of estimates we provide.

The next question: Does Management really mean it when they say “We won’t hold you to it”?

The truth is, they will hold you accountable for the number they receive.  No one in leadership is going to say: Pull a number out of the air, and wink-wink, we know it’s way off. But no worries, I know you threw a dart at a board of numbers and just gave me the result squared.

What they are really saying is that they need an estimate without going through the typical rigor of process that may take days or weeks.  I am not looking for a plan with milestones and staffing requirements.  I am looking for an overall high-level plan without that detail information. So don’t try and cover yourself on this. I won’t create pain for you.  Just give me the high-level estimate.

They may not understand, that getting them the high-level estimate requires us to build the details.  Only then will the high-level numbers have enough validity so they can make business decisions based on them.

A Best Practice: Communicate Your Concerns! Call Them Out on It

The next time management says I need an estimate but I won’t hold you to it, call them out on it! Ask them what they need the estimate for and what decisions will it be used for.  Are they looking to free up resources?  Are they putting in a budget request? Ask how painful it will be if the estimate is off by x%?   Odds are they may pad the estimate (their budgets) for planning purposes.

Start having a conversation so you can truly help management as best you can, and as a partner.

One thing is for sure, if they are asking you for an estimate, they are using it for business reasons. And, bottom line, you will be the owner of that estimate!

Estimating is a Minefield!

Estimating can be a minefield. Everyone asks for estimates. We ask a child how long a chore will take, or when they’ll be home from a party. We ask a boss when our review will be done.  Marketing has been asking me when will I have this blog article complete? (By the way, they clearly tell me they will hold me to it!)

We need a consistent language around estimating and more importantly, we need consistent expectations around how we estimate and what we “can” and what we “can’t” estimate, repeatedly and predictably.

So the next few articles are going to focus on common obstacles that cause a team estimate to either be order-of-magnitudes incorrect or simply an estimate that does not command everyone’s confidence.

We’ll start next post with about padding estimates and why we should NEVER do it.  I will present you a better alternative.

So, how many times has management asked you for an estimate that you won’t be held to?

Photo Credit: Denise Chan

Software Requirements: Are The Business People With You?

The Role of the Business in Driving Software Requirements Definition

Many of us believe that the single hardest part of building a software system is deciding precisely what the business needs. No other part of a project has as much impact on the final outcome as requirements definition. Yet, the requirements process often ends up as the area most lacking in best practices.

I recently participated in a survey of IT executives at a Chicago trade conference. Some of the results of the survey were what I expected and some were surprising. But either way, the results are very relevant for teams looking for perspective on their own development practices. This week, I’ll report some of the basic findings of the survey.

Respondent-Roles-1

Most of the executives in the survey recognized the importance of accurate requirements and admitted to routinely struggling in two areas: Connecting with the business and managing requirements throughout the development cycle.

Key Survey Findings

  • 94% of respondents acknowledged that the quality of requirements is a leading factor in the success of their software projects.
  • Over 70% acknowledged that there is room for improvement in their requirements practices.
  • 75% agreed that better articulation of business and IT roles/responsibilities in requirements gathering would go a long way toward improving project outcomes.
  • While most admitted that the business has at least some input with requirements definition, requirements are often unclear.
  • Over 80% of respondents indicated that they do not learn about missed requirements until too late in the project development cycle.
  • Only about half of the respondents felt that business and IT teams have a consistent view on project status.
  • Over one third of respondents stated that progress is not consistently tracked in business milestones, resulting in rework and missed deadlines.

 

It’s Unanimous: Business Involvement Has a Big lmpact

It is not uncommon for business stakeholders to “throw their requirements over the fence” and expect to come back later to a successful working system. In practice, however, this approach leads to rework, project delays, cost overruns, and other disappointments.

Although the degree of business involvement varied within the survey, respondents overwhelming agreed that when the business is directly held accountable for clearly defining their needs, project outcomes improve. Respondents also mentioned the need for better articulation of business and IT roles and responsibilities in the requirements process.

ssp_temp_capture

Business Milestones: Now You See them. Now You Don’t.

Another big area of concern for survey respondents was managing requirements throughout the project.  Most agreed that project metrics must define progress and value in terms the business understands and appreciates. Approximately 50% reported that business and IT teams in their organizations share a consistent view of project status.

ssp_temp_capture2

Another important benefit of using common metrics is more awareness of when requirements are due. All too frequently, IT learns about missed requirements too late in the development cycle.

In the case of the survey, all agreed that it is critical to find out as early as possible whether key requirements are missing. However, most respondents indicated that they become aware of missed requirements during User Acceptance Testing (UAT) or after deployment.

What level of commitment do the business stakeholders have in requirements definition in your organization and how does this impact project outcomes?

Next week, I’ll write about some of the steps you can take to pinpoint the areas of your organization most likely to interfere with your ability to satisfy business expectations.

Changing the Conversation on Software Requirements: Collaboration in the IT Team

motion gears -team forceDelivering Business Value is a Team Sport

Last week, I talked about how to change the conversation of better software requirements from creation of the “perfect” requirements documentation to establishing joint accountability between the business stakeholders and the IT team for the success of the project. This week, I want to talk more about how this approach can carry into the detailed phase of the project.

In July I attended my company’s “Tech Talk”.  My company, a software development company called Geneca, regularly holds Tech Talks to give employees the  opportunity to share technology information. Even though I am no longer particularly technical, I like to attend these sessions in order to keep up on the technologies that my peers and the industry are using.  At the last Tech Talk, Chris Johnson (one of the developers) spoke about a high-productivity web framework for Java development. I know – you’re asking “what does this have to do with better requirements”.

What really excited me about Chris’s talk (since I didn’t really understand all of the coding detail) was when he explained that one of the big advantages of using this technology was that he could partner with a Business Analyst (BA) during the requirements process and actually create web prototypes while the business was explaining what they needed.   The business stakeholders could see how the team was envisioning delivering the solution and give immediate feedback. The developers would also get a head start on the code for delivering the solution.

To me, this was an excellent example of how the entire IT team can work collaboratively to deliver true business value. My co-worker wasn’t holding the BA solely accountable for ensuring that we had the correct requirements.  Rather, he was making the conversation about ensuring everyone was accountable for understanding what the business really needs and for delivering business value. And, by working together, all parties (the business stakeholders, the BA and the developers) can better share a common vision of the solution.

Think Beyond the Requirements Document

I have worked in other environments where the BA would have been threatened by the idea that a developer could create a working prototype during requirements definition. By including the developer (or a PM or a tester) in the requirements process, there might be fear that the BA role would be devalued. But, a good BA needs to understand that the role of requirements definition is not just in the realm of the BA. In fact, ownership of the requirements really belongs with the business stakeholders. The role of the BA is to help communicate the business vision to the rest of the team, by whatever means works best.

Rather than focusing on the requirements document as being central to their existence, the BA needs to find the best vehicles for communicating the business vision to the rest of the team and for ensuring that the team works together to deliver what the business expects. This can be through written requirements, through diagrams, or verbal communication. Or it can be by including other team members – the PM, the developers, QA tester – in the requirements process so that entire team understands the vision and is focused on delivering business value.

When everyone on the team is working collaboratively and holding each other accountable to meet the project’s business objectives, then the project will be a success – regardless of whether the requirements documentation is perfect.

How does your IT team insure that they are delivering business value?

Changing the Conversation on Software Requirements: The Role of Business and IT

What, Truly, Is the Role of a Business Analyst?

Arper-Aston-Office-Chair-IncaseRecently I came across the question “is a written [software] requirements document really necessary?” in a Business Analysis forum. I found the question intriguing and had to look at the discussion around the topic. A lot of the discussion revolved around methodologies (Agile vs. Waterfall) or around requirements techniques (diagrams vs. words). One responder claimed that “the creation of the requirements document is central to BA’s business existence.”

I was bothered by this direction of the conversation. To me, if “the creation of the requirements document is central to their business existence” then the Business Analyst (BA) is not focusing on the right way to improve requirements or to ensure project success. To me, what is central to a BA’s existence on IT projects is to focus on ensuring that the team is providing the agreed to business value for the client. Any documentation is simply one method of communicating the business need and what success looks like to the business stakeholders.

Poor requirements or scope creep are often listed as top reasons why projects fail. We’ve all heard statistics, such as, “more than half of all IT project fail to meet the business requirements”. At a recent webinar hosted by Geneca and Forrester Research, the Forrester analyst pointed out that finding and fixing a software problem after delivery is 100x more expensive than finding and fixing it during the requirements or design phase. Obviously there is a need to ensure that the requirements process is successful.

Think Beyond the Documentation

However, is creating “better” documents going to provide this success? Is more and more documentation going to provide this clarity? Is developing the “perfect” template going to solve the problem with requirements? If the focus is only on improving the requirements by creating better documents or providing more documentation, then I believe that the team is missing the root cause of why the requirements need to be improved.

Most of the BAs that I have worked with are competent and create readable documents. Although they work diligently at capturing all the project requirements, projects can still go awry. The business complains that IT isn’t delivering what they asked for. IT complains that the business doesn’t really know what they want. Business stakeholders “sign off” on detailed requirements documents without really understanding their content. Development teams create software without really understanding what it is that they are delivering.

Perhaps what we need to do is to make the conversation about understanding what needs to happen in order to accomplish the goal of providing true business value. To do this, the business stakeholders need to be accountable for defining what is of value to them – defining what success means. And, all of the business stakeholders for a given project need to be aligned on what success for the project means. If the stakeholders don’t have a common vision of what success for the project means, how can IT be expected to deliver a successful solution?

Create Clear Accountability for the Definition of Success

Likewise, IT cannot tell the business what success is. It is not their job to tell the business what they can and cannot have. The IT team needs to be accountable for listening to the business stakeholders, understanding what success is from the business’ perspective and then communicating what it will take to deliver to that vision. IT can offer alternatives and suggestions on ways to deliver to the business’ vision in a timely, cost-efficient way. But, ultimately the business stakeholders own the decision on which alternative to accept. The entire team – both business and IT members – are then jointly accountable for the success of the project.

In this environment, the role of the BA shifts from just being a creator of documents to being accountable for communicating this common vision to the IT team and helping ensure that they provide a solution that meets the business vision. The requirements documentation becomes just one of many vehicles to help accomplish this goal, not the end goal of the role.

What is the expectation for the BA in your organization? Are you expected to be a documents creator or to take a more active role in ensuring that the right solution for the business is delivered?

Next week, we’ll talk about how to carry the common vision throughout the project in order to deliver a solution that truly delivers business value.

Photo Credit: Incase