An estimate can be generated in number of ways.
One way is for all the work to be planned up front in sufficient detail to be able to know that you can assemble the target 'end-product.' Another way is for you to use analogy, such as using your experience to estimate the size of the work package. Simply put this is top down and bottom up estimating.
There are many techniques that you can add into these approaches including function point analysis, cocomo, monte carlo estimates, team velocity and so on. These techniques are beyond the scope of this post. What I want to focus on is the space between the top down and bottom up approaches to estimating.
In my experience - commercial projects from small (3 people, 3 months) to moderately large (30 people, 3 years) I think the real answer is a blended approach.
All estimates are made from experience and judgement. Balance your team's experience and judgement with countering views.
For instance many projects suffer the problem of overly large estimates pushing the project cost beyond the realms of valuable. Management will often push back with a 50% cut or similarly arbitrary approach.
If on the way to the end estimate you apply some top down constraints - say we have to have reached a valuable and tangible outcome within 3 or 12 months you can help guide estimating and planning decisions around functionality and performance criteria. Of course reasonable contraints need to come in from a value perspective; "We expect to invest this much time and effort for that much value." And that is where you analogous estimates are useful.
Of course, estimating is not a one way street in either direction. It's a collaborative effort by the project management team and the people on the team who need to do the work. Checks and balances, right?
And no making promises you can't keep.
I recently saw an email from a project sponsor that simply replied "SCOPE CREEP!" in response to the BA's concerns about whether the report being made as part of the project was going to adequately cover the business needs of the client. The BA had suggested a few additional requirements, like formatting and additional fields to include in the report. This was after the charter was written, but before the user requirements had been captured. I was flummoxed by the response.
How exactly is this scope creep? It seemed to me the scope of the project was "create a report for the client" along with some basic information about what the report would contain. In our organization's process, the charter is usually fairly high level, and is followed by a requirements analysis from a BA who comes up with the specific details for what the product should do. In my mind, the BA was simply fleshing out the requirements. If the BA had suggested a second or third report, sure, I'd (reluctantly) call that "scope creep."
And furthermore, even if the requirements deviated a little from the original scope, what's the point of making a report that's not going to be useful for the client? Should the original scope be strictly stuck to come hell or high water, even if it results in a shoddy product? Is a project one that just stuck to scope? No!
"Scope Creep" has to be one of the most used and abused project management-related terms out there, and sometimes I want to find the person who created the term and shake them. To be sure, many projects fail because the scope got out of control. But I'd argue that the real reason those projects fail was that the original scope was never clearly defined in the first place. It's easy for the scope to change and a project to be delayed if there was no clearly defined scope to begin with.
The PMBOK never intended scope to be something that was set in stone. It just states that it should be defined at the beginning of a project, and any changes should be reviewed, and approved or rejected based on whether they're deemed worth it to the project. The whole point is to look at changes critically and make smart decisions about them. And yet, scope seems to be one of those things that some PMPs and "armchair" PMs seem to cling to as the most important part of project management.
At a PM class I took last year, the instructor asked the class what they should so, as PMs, if someone asks for a change to the project. I was surprised that many of the answers were along the lines of "explain that the change does not fit within the project's scope and that we cannot proceed with it." I wanted to tear my hair out. Being the "scope police" is not what being a Project Manager is about. To be sure, we have to be careful about the scope of a project, but change is not always a bad thing, and sometimes, if dealt with effectively, it can be one of the most important elements of a successful project.
So, I'm hereby proposing we retire the term "scope creep". It's too easy to cling to as a buzzword, and distorts the role that scope should play in a project. Any suggestions for a replacement?
The video below has a running time of 26 minutes and is incredibly fascinating. I can normally watch about 2-3 minutes of a video before boredom sets in, yet this one hooked me and held me all the way through.
One of my biggest annoyances is touched on in this video, and that is the subject of 'information overload'. I'll let the speaker explain why he believes it is a bogus term, but I have echoed his feelings for many years. The problem is not how much information exists, but in the ways we deal with the information presented to us. As a demonstration of this, I'll use my methods for dealing with an unwieldy email inbox.
Feeling overwhelmed by information is a phenomenon that plagues most knowledge workers, but can be especially bad for those of us who spend most of our time working on projects. Between the business areas asking questions about projects from three years ago, the business areas asking questions about current and future projects, the QA team, our management and the support desks, it can seem like waves of email crashes our inbox with alarming frequency. Not only do we receive requests from all over the company, the subject matter contained in those requests can vary so wildly from one to the next that its hard to get in a groove and keep all the separate conversations straight.
When you look at my inbox, he first thing that you'll probably notice is that it is usually almost completely empty. I may get dozens or hundreds of emails in a day, not to mention the veritable deluge that is my RSS reader, yet it never backs up to a point where I can't parse it in a relatively short time.
Sure, the longer I am away from my inbox the more the unread count climbs, but even after a week away from the office, I can usually knock through an initial culling of the entire inbox in 30 minutes. This culling removes out the items where I was copied as a courtesy, any spam that made it through my filters and any items which were resolved prior to my reading about them.
Once I've removed all the items which don't need my attention, all that remains are tasks I need to complete. Tasks are loosely defined here as a decision I need to make or a function I must perform outside of my inbox. If the task is something that I can do short term (24-48 hours) it stays right there, staring me in the face. If I have to look at it, and look at it against that stark white background of an otherwise empty inbox, I know this one needs me. It is calling out to me that it must be completed.
If I can't get to it in 24-48 hours, or if my work is done and I am waiting for someone else to get back to me, I flag it for follow up. How this flagging works is very dependent upon your email provider, but almost all modern email applications provide some mechanism to mark an email for later review. By adding this flag, I don't lose track of the note in the deluge, but I know my part is as done as it can be for the moment. I've essentially checked it off a list, but it is still there, easily retrievable.
Now, I'm going to contrast my inbox with a fictional coworker of mine I'll call Sue. I've known many people like Sue, so while she's not real, the behaviors are very real.
If you asked Sue what the worst part of her job is, she'll likely say dealing with email. She'll tell you all about how she's horribly far behind and how she never has time to get around to cleaning out her inbox. When she does finally get around to her inbox, she routinely replies to emails either reading the entire thread first. This causes people like myself to shake our heads about how she just wasted her and everyone else's time on something that is already taken care of. Sometimes Sue brings up amazingly good points in her replies, but because she is not timely in her response, she causes everyone else a great deal of rework.
Sue is also notorious for not seeing email at all, and thus missing many items which need her specific attention. Those of us who work with Sue routinely drop by her desk after a day of receiving no response, bringing up the issues in person because her input or blessing is needed. Not only did this waste more of our time, it really wasted Sue's time because eventually she'll find the email and she'll still have to deal with it, even if she doesn't have to type out a response.
It is my firmly held belief that one of the most rude things you can do, both at work and in our private lives, is to deliberately waste someone else's time. Just as I am a stickler for removing people from email replies who have no need to be copied, and thus saving those people's time, I want people to not copy me if my input is not needed. My time, and everyone else's time, is a valuable commodity, one that feels like it is shrinking all the time. We all complain about how our management drags us along to useless meetings, wasting our time, but our time can be just as easily wasted sifting through mounds of useless or untimely emails.
Sue is known for being a contrarian when she thinks she is being left out of the loop on even the smallest detail. She may not be in any way impacted by the subject at hand, but let her find out that you've 'been holding out on her' and you should expect to hear all about your failings, in detail. Despite knowing that she can't keep up with her email barrage, Sue still insists on you copying her on every email because someone might ask her three months from now what she thought about the discussion.
So what are some things that Sue (and maybe you) might do to help dig herself out of the hole? Lets take a look at a few ideas.
Stop digging.
When you're at the bottom of a hole, you must stop digging deeper. Sort your email by date, select anything older than today and file it completely.
Delete it if you think you can't help yourself but to go back and look at it later. Remember that your co-workers know you don't get to emails in a timely fashion, so they will stop by to see you about it (or will forward it back to you again).
It might even be worth your time to tell your commonly contacted associates in advance what you're doing so if you don't respond and they need you, they should try again.
Delegate.
Especially if you are a people manager, delegate tasks that can be performed by others.
This not only helps them grow in their positions, but it helps you in two ways. First, it does keep the inbox from filling up and second, you can use it as a method to grow as a mentor to your team. The key here is to use the delegatee as your filter.
Give them clear expectations, up front, on when they should raise something to your attention and then don't get mad when they follow the rules and don't tell you every single detail. Your delegatee will fail, probably numerous times, but assuming you selected the right person, they will eventually get it right and you'll both be better off.
Sort.
One of the things I love about Gmail is its conversational display.
No matter how many times someone replies to an email, its all nice and formatted in a single long chain. One click, some downward scrolling and you see everything that has happened since your last check of the thread.
Sadly, many email programs used in offices have not adopted this view. In this case, sort by the subject line and then by time, then read through the responses from oldest to newest. By looking at your email by subject, you can quickly determine where the conversation is at this moment and reply accordingly (or preferably not at all, if you're very far behind).
Filter.
Another great item contained in most email programs is to apply filter rules.
Do you get a lot of automated notifications? Create a filter rule and have those emails pitched into a special folder. Are certain senders more important? Have them automatically highlight in a different color so your eye gravitates to them above all others.
Search.
Don't waste a ton of time filing. Another great innovation in Gmail is the ability archive and then to search your entire mailbox.
Why waste all that time trying to find out where you put that email when, in a few keystrokes, a quality search engine takes you right to the email.
Humility.
I probably just lost a few of you with this point, but I'm using the term here a bit differently.
Know when your input is needed and when it is not. If everyone else has it covered, don't feel obligated to put in your $0.02 just because you can. The Reply To All button is a great power and thus, a great responsibility. Use it wisely.
With a few simple steps, we prove that information is manageable, but we must have a plan for dealing with it.
Calling it informational overload and doing nothing about it is a recipe for failure and frustration, for yourself and for those around you. We must use the technological and relational filters at our disposal so we can focus on the items that are truly important.
If we feel ourselves drowning in data, if we have information indigestion, the problem is not with how much information people send us but how we manage what is sent.
If you're reading this and you are a Sue, why do you feel you can't manage all that information? If you're like me and deal with it well, tell us how you manage it all so well!
This is where I find myself at a loss when working in an Agile environment. I know that only the user stories that are being worked in the current sprint are expanded. These user stories encompass a subset of requirements for the project. But at what point do those of you doing Agile find the simple 3x5 cards become unwieldy? At what size project do you start to say "Maybe we need something to keep track of these user stories"? And more importantly, where do you turn when you reach that point?
Net Objectives conducts a series of webinars on Business Driven Software Development:
This series provides an introduction on how to achieve Business Agility. Business Agility enables an organization to respond quickly to external forces (such as new market opportunities and competitive forces) as well as to respond quickly to new insights attained internally. While many organizations have achieved the local optimizations of more effective teams, few have achieved agility at the organizational level. Even when team agility has been achieved, if improvements to how the business is selecting their product enhancements isn’t done, overall return on investment of software development may not have significantly improved.
First event is tomorrow at 9 AM PST. Register at the event page to attend the webinar.
Posts
