I had a great conversation last week with someone taking a leadership course. (Not one of my courses. His instructor wouldn’t talk to him!! He’d seen one of my posts and emailed me. Of course I talked with him.)
He was confused by the word “Handoff.” He thought it meant that people hadn’t done their job and other people had to cover for them.
Sometimes that happens. But more often, handoffs occur when you bring people together in a complex project or program, and they deliver their parts to make it a whole.
Here’s the analogy I created for him during our conversation. Imagine you’re a chef at a famous restaurant, creating a great dining experience for your customers. You have the meat chef, the potato chef, the vegetable chef, the sauce chef, and you, the lead chef, all bringing the dinner together for the customer’s delight.
Not all meals need a lead chef, but sometimes they do. In this example, they do. Why? Because my colleague has a new team of volunteers who don’t know how to perform their tasks. He is the master chef. He’s not command and control. But he needs to show them the first few times how to put everything together. Does this sound like some new-to-agile teams, working with a coach, to you? The coach isn’t a master chef. The coach is a facilitator. It’s a little different. Okay, back to our example.
My colleague, in his role as master chef, asks each chef to handoff their parts to the plate. (Integration to the software people.) As master chef, he would do the clean-around-the-outside-of-the-plate thing that master chefs do, add a sprig of herbs, handoff the plate to the server and now the plate goes to the diner for a delightful culinary experience.
As the people in the kitchen evolve, they don’t need the master chef to supervise them, do they? No, they become a self-organizing team who can do this by themselves. But, they still have handoffs, because the meat chef still focuses on meat, and the potato chef still focuses on potatoes, etc.
In kitchens, chefs are trained to be generalizing specialists. In software, we aren’t always trained. But we can learn, if we want. We can pay attention to the handoffs.
In an agile team, especially with continuous integration, we don’t notice handoffs. Continuous integration makes handoffs trivial. If we work together to achieve a feature, as in swarming or mob-programming, we don’t even have handoffs.
In a non-agile or when you don’t have software, we want to know when the handoffs occur, so the team can synchronize around them. In a geographically distributed team, we want to highlight the handoffs, so we know what to expect and when.
Handoffs aren’t bad. It’s how we manage them that can make them good or bad.
It has been suggested that context is somehow irrelevant. This notion seems to start around the criticism of the MoSCoW requirements method where requirements that implement the needed capabilities of a system are categorized.
MoSCoW means: (how it got the moniker I have no idea) and is a well developed method of eliciting requirements in a paradigm where the customer has some notion of what done looks like. If this is not the case, no method will help and the norms of project management are no longer effective - it's a Chaos mode. So in fact MoSCoW has no value and the suggestion may be true - in Chaos we don't need requirements elicitation methods.
But let's assume we're not in chaos and we actually would like to know something about what Done looks like, how much it might cost to get to done, how long it might take, and what of value will be produced when we reach done.
But for projects operating in the other three uncertainty modes - variaton, foreseen uncertainty, and unforeseen uncertainty, the first question is actually the inverse question ...
Why would we NOT prioritize the requirements using this or a similar mechanism?
Let's look at some content in the notion that prioritizing requierements should be ignored. A requirements Trade Space is mandatory on any non-trivial project for some very simple reasons:
Below is an example (at the end) of a program that has a minimum set of capabilities fulfilled by the requirements, where the Program Manager and the Customer managed the success with ruthless adherence to a schedule and the needed capabilities.
This example might serve as a paradigm for other mission critical projects.
Now the question is can this paradigm or context be applicable to small group, agile software projects? Turns out Star Dust had small team software intensive software components. As Shim says think about it.
Focus on the nine I's (v9) from Glen Alleman Related articles What's Missing from Project Management in IT Agile Paradigm A Common Myth in Software Development They Never Saw It Coming
Are you transitioning to agile? Is it going well?
If it your transition is going well, excellent. I’m happy for you. But if you are like many of the leaders across the organization I’ve met, you have plenty of problems. Sometimes you have a problem as this colleague said,
Right now we’re really struggling with Portfolio Management that is relevant to our business. We can’t prioritize because we can’t define projects in a way that resonates with the business.
Resonating with the business is an issue of influence. How influential are you? Would you like to succeed in managing the project portfolio? Or, in getting the testers/QA involved at the beginning in a real cross-functional team? Or, helping people realize that fast failing is good? Are you ready to prepare to become more influential?
Join Gil Broza and me at The Influential Agile Leader in Toronto, April 8-9, 2014. If you’re in Europe, we’ll be in Edinburgh, Scotland, May 22-23, 2014.
We’ll experience and practice authentic approaches to influence and coaching. (Of course this is experiential. What did you expect?) Where is your sphere of influence? How do you expand it? How do you influence within it? You’ll have a chance to practice with your peers in real situations.
We’ll help you learn how to coach up, sideways, and down. Up is especially critical. For example, you might have to explain options in different ways when you coach up. Again, you’ll practice, using real-life situations.
There’s much more that we can offer. You, the participants select the rest of the program. We will deliver, experientially, what you want at the time. We are prepared. We’ve done our work. You will drive the rest of the event.
All the details are at the Influential Agile Leader.
Please join us. Early bird registration ends Dec 31.
Sign up now. You won’t regret it.
From the Ask Tom mailbag -
I just picked up a book on tribal leadership that suggests hierarchy is an old fashioned, out dated approach to organizational structure. Your workshop suggests that hierarchy is the only approach to organizational structure?
I hear these things from time to time, about how hierarchy should be abandoned and replaced with throwbacks to earlier organizational models and, as you can imagine, I am not overly impressed. First, understand that there are many purposes for groups to organize. Groups may come together to worship, promote political causes, live as families and communities. Each may engage in different organizational structures, collegial, political, religious, family. When I promote hierarchy as a structure, I am referring only to those groups of people organized to get work done.
And some work does not require a complicated structure. But, gather any group of people together and give them a task to do, they will self-organize into a structure to get the work done. First, a leader will emerge. That person does not have to be assigned that role, they will simply emerge from the group. If the group task requires several separate, simultaneous actions, people will gravitate to roles and cooperate, under the guidance of the leader to complete the task assignment. If the task is of sufficient difficulty, requiring problems to be solved and decisions to be made, that organized group will take on the shape of a hierarchy.
I know there are organizations, designed to accomplish work, that self-proclaim a flat, tribal, non-hierarchical structure. Baloney. If the work is of sufficient complexity, and you examine the related tasks and people playing roles to complete those tasks, you will find hierarchy.
No tribe ever sent a man to the moon.
Proper Preparation Prevents Poor Performance
This simple phrase describes the core behavior of all project related work. For any platitude to survive contact with reality, it must be true, actionable, and applicable in your own domain.
The notion that “emergence” is the driver for the participants in a project requires careful consideration. The technical or business requirements of the outcomes of the project are always “emergent” in some form. To be otherwise would require a preset group of activities, materials, technology, and personnel.
Failing to understand the subtleties of the continuous emergence of requirements, that enable the capabilities to be delivered, means failing to understand any project requires planning to deal with these emerging requirements. This emergence also pertains to the tools and processes used to manage and deliver the project. emergence is applicable to all elements.
Preparing for Emergence is a critical success factor in project work. Proper preparation is the foundation of programmatic and technical risk management. This means asking and answering the “if – than” question, rather than the “what – if” question.
Managing in the presence of emergence requires directed decision making. Just letting things happen disconnects the outcomes of the project from the neeed capabilities produced by the project. These capabilities are the immutable part of the business process. They can only change, when the strategy for the success of the business enabled by the project changes. To do otherwise, would be to disconnect between the investment in the project and the value produced by the project.
“If – Than” means knowing what can go wrong and how to respond to the following:
From the Ask Tom mailbag -
I recently attended one of your Time Span workshops and want to know how hierarchy promotes cooperation?
The short answer is accountability. Inherent in the structure of hierarchy is accountability. Unfortunately, most managers misunderstand the purpose for hierarchy and where accountability is appropriately placed.
Most managers believe that hierarchy is a reporting structure. Even our language misguides us. ”Who is the new guy going to report to?” This is not the central question.
The definition of a manager is, that person held accountable for the output of other people. The question is not “who should the new guy report to?” The central question is, which manager can be held accountable for the new guy’s output?”
When managers begin to understand accountability, the whole game changes. Hierarchy provides us with a visual representation, of which manager is accountable for the output of the team.
When managers begin to understand that they are accountable for the output of their team, attitudes change and behavior changes. Behaviors change from controlling and directing to supporting and coaching. Every employee is entitled to have a competent manager with the time span capability to bring value to their problem solving and decision making.
The purpose of hierarchy is to create that value stream, where managers, one stratum above (in capability) bring value to the problem solving and decision making of their team members. For ultimately, it is the manager who is accountable for their output.
Plans are nothing, Planning is Everything
The notion that plans are nothing but planning is everything is a common mis-applied quote. The clip art and content extracted from the current edition of Defense Acquisition Journal, November-December, 2013.
The ever-quotable Dwight D. Eisenhower, speaking to a group of industry executives who could be mobilized for war at a moment’s notice, was echoing an old adage about warfare: “No battle plan survives first contact with the enemy.”
Eisenhower’s message, like the man himself, was straightforward: “The reason it is so important to plan [is] to keep yourselves steeped in the character of the problem that you may one day be called upon to solve—or to help to solve.” He was reminding them that warfare is inherently fluid, and that the only way to adjust to quickly changing circumstances is to have planned for such contingencies in advance.
For our project management domain, Plans are considered Strategies for the successful delievry of the project's capabilities. But this strategy is actually a hypothesis and this needs continual testing. The best way of course if testing the hypothesis is working product at periodic points in the project. Some would say this test should be every few weeks. This of course - as always - is domain dependent. But at a minimum every month.
In our Earned Value Management domain, the montly Contract Performance Report (CPR), requires an assessment of physical percent complete to calculate the BCWP (Budgeted Cost of Work Performed). The planned cost of producing this value is BCWS (Budgeted Cost of Work Scheduled).
BCWP = BCWS x Physical Percent Complete
On the planned day for the planned cost. Don't show up on the planned day for the planned cost and the planned physical percent complete? You can't be on schedule and on budget.
Now Add Technical Performance Measures and Quantified Backup Data
The determination of Physical Percent Complete starts with Quantifiable Backup Data. Percent complete is never a guess or an opinion. Tangible evidence is needed. But tangible evidence against the planned percent complete, on the day we planned to be that percent complete. This is nearly identical to Agile's approach to delivering working software at the end of an iteration. Not quite, since agile allows you to drop planned deliverables without an penalty to the current performance measure. This mortgaging the future by pushing undelivered features into the future would not be counted as complete in Earned Value.
When I talk about interviewing an agile team, many people think, “Oh, we should pair!” and that’s it. But, many teams don’t pair regularly. If you pair in the interview and you don’t pair at work, you have an incongruent interview. That’s not helpful to you or your candidate.
Instead, you want to create an interview that’s congruent with the way you work as an agile team right now. Not the way you want to work in the future. The way you work right now.
You want to make the interview so compelling that the candidate asks for a tour. You don’t want to waste time on a tour, selling the candidate. Let your questions and audition sell the candidate on you.Create your Areas for Questions and Audition
Evaluate your practices first. What do you do as an agile team? Do you pair? Do you do continuous integration? Do you ask each other for help? Do you coach and mentor each other? Do you collaborate? Do you stop when the customer/product owner says to stop? Do you get feedback often, either during the iteration or as part of your kanban? These are examples. I got carried away…
Whatever you do, decide which areas are essential for questions and which area(s) you want to investigate by audition. Unless you are like Menlo Innovations, where everyone pairs all the time, don’t hire just by pairing.
Instead, create an interview matrix. The matrix will tell you who will ask questions about which areas. You want a little overlap. Not much.
Create behavior-description interview questions. Have a conversation with the candidate. The conversation will provide you clues about cultural fit.
Create an audition. Choose a practice or two from the above evaluation. Either give the candidate something to work on, or work with the candidate together (you are an agile shop, right?) and see how things go. Does the candidate want to check in work every few minutes? Does the candidate want to wait? Neither is good or bad. They just are.
Test the audition with the interview team to make sure the entire interview team could pass the audition. If they can’t pass the audition and they work there, how could anyone else pass the audition.
Now you’re ready for interviewing. Bring on the candidates!Meet After the Interview
After you’ve met with a candidate, follow up and decide on each candidate with a brief meeting. I suggest a consensus-based meeting for this. Limited consensus might be fine, and you have to know your team. You are the ones who will have to work together.
Next and final part: Hiring remote people.
We hear all the time, pithy statements about teams, teaming, team building, enabling team that provide innovation, and most every soft skill ever thought of, applied to managing projects. At the project below, where I was one of many program managers, we came to realize one fundamental truth about teams -
If you have a team who is your opponent?
Having played team sports at the High School, College, and competitive adult level, our teams always played against an opposing team. Much of the team building platitudes seem to ignore that teams are formed to play other teams, score points, win games, overcome obstacles, and participate in competition.
Who is the other team if we're on a project team?
See if the notions below resonant when you hear short, cleaver words about the role of teams on projects?
Making the impossible possible from Glen Alleman Related articles Agile Requires Discipline, In Fact Successful Projects Require Discipline Trust 5 Benefits Team-building Consultants Can Offer Your Business Competency Model For Project Managers
The first question is who pays for people learning from their mistakes? Then the next question - with these mistakes, did the project advance in ways it would not have before we made the mistake?
And did the money we spent learning from our mistake "earn its value?" Or put in another way was there a better use of the money to advance our learning other than building something that we considered a mistake?
There are other questions as well. Why didn't we know this was going to be a mistake before we started? Or could we have known this before we discovered it failed? Or even better, was the failure we just experienced knowable at all?
This knowability question is the key to all project planning processes. If something is not knowable, then we could not have known, so we only discover our mistake after the fact. If it was knowable and we choose not to address it - ignore the potential problem - then we'll overrun our plan for no good reason other than we choose to ignore the knowable facts.
We may have a knowable issue, but can't afford to learn (pay money to learn), but that's different.
These questions and others need to be asked and answered before we can make any assessment if learning from our mistakes is a good idea. The alternative to learning from our mistakes is to do the job right the first time.
This of course is overstating the solution and somewhat silly, but it brings out a critical concept that must be addressed in any credible management process of spending other peoples money...
Who pays for the development team to discover their mistakes, if these mistakes could be avoided?
Once we have the answer to that question, we now have some decisions to make.
This is all fancy words for someone has to pay for us to learn what we don't currently know. And we need to make the cost of this learning visible as soon as possible if we're going to be good stweards of other peoples money.
So What's the Point?
The notion of Hiring smart people is pointless if they aren't allowed to make any mistakes ignores the managerial finance obligation to determine who pays for these mistakes, is the budget for making these mistakes in the baseline authorization, and if not, are we going to overrun our planned cost for the project and dilute the Return on Investment calculation that we sold to the owner of the project?
We seem to forget that writing software for money, means spending other peoples money for the expected amount of money (within the variance bounds) and showing up on or before some expected time (within the varaince bounds), with more or less the expected capabilities.
This is a Prime Directive (to borrow a phrase) for all projects. It's very doubtful the owner of the money says to us hey boys and girls, go out there and experiment around to figure out what will work and what won't work without actually budgeting for that experimenting work.
When there is explicit budget to experiment that's called explicit work for discovering what we dont' know, that is needed before we can proceed. We'd find that budgeted work in our plan for the project. No problem, all part of the normal project management process.
But the notion of Hiring smart people is pointless if they aren't allowed to make any mistakes needs to address Who, What, When, Where, Why, and How this discovery process is going to get paid for FIRST, then we can start failing on purpose to make the follow on work better.
But let's start with a fundamental principle of all business, not matter the domain. If we expect to generate revenue or produce some measurable value from our work efforts, we need to measure those beneficial outcomes in some agreed upon units.
Dollars is one unit of measures common in the business world. If we work are a for profit company, it is likely the managers of the business use that unit when they discuss project work. If we work for the government, budget is used many times in place of cost, but cost - in dollars - is still in the equation. If we work for a non-profit or a not-for-profit budget and cost are half the equation. Intangible benefits the other half.
But it is unlikely any place we work, there is not some discussion of cost, budget, or expenses. So no matter what our personal opinion creating estimates of our work effort are, we can't escape the fundamentals of business.
We need to know the cost of something before we can assign a value
Let's look at some deep truths about estimating
So The Big Question?
These issues are not unique to software development. They are found in every project domain. Public works, bio-pharma, energy, government contracting.
Estimating is hard, it's important, and needs to be addressed in much more detail, before being dismissed as simply something management wants.
It's not clear how this notion came about, since I haven't talked directly with those making statement like that. I'll have to estimate myself why this might be true.
One reason might be they haven't been exposed to the statistical processes used to make estimates in a variety of domains, not just project management. When we encounter the need for estimates, we need to come in contact with probability and statistics. All processes on projects are statistical in nature. This produces uncertainty and uncertainty results in probabilistic outcomes.
Estimating means searching in this probabilistic "space" for a number that is close enough to answer a question. How many people are in line for movie tickets inside? Should I buy my tickets at the kiosk outside? Or maybe, how long will it take me to drive from my office to the airport parking garage for my flight on Wednesday morning? These are not exact numbers, these ae quick estimates. The answer to the first question can be made with a quick look inside the theater. The second comes from the experience of driving to the airport several times a month over the past 20 years. One is informed by observeation of the current situation, one informed by past experience under a variety of situations.
Let's start with a simple definition of an estimate - it is an approximation of some value for some purpose, even if the data is incomplete, uncertain, or even unstable. Typically the estimate is derived from a statistical source of data - either observed or referenced in some way.
Making Simple Estimates
When we don't have the exact answer of some value, we can make an estimate of that value. The result is a number and a confidence on that value. Say we need an estimate of how long it will take to drive to the airport. It's 52 miles. Some on surface streets, some on open 2 lane roads, some on freeways. Knowing the speed limit for each of these segments can get us an approximate time portal-to-portal. We can improve the estimate, knowing the weather conditions and the traffic flow on the surface streets.
Let's look at five easy steps for making estimates (abstracted from The "Mother of All Guesses" - A User-Friendly Guide to Statistical Estimation, by Francois Melese and David Rose COPYRIGHT ARMED FORCES COMPTROLLER, 1998)
Making Estimates for Project Work
With the steps above we can start to make estimates of our project work.
But first let's kill some myths used to not to make estimates.
We've heard them all and more. There is an endless list of reasons for not doing most anything on a project, but that doesn't remove our obligation to be stewards of other people's money we are spending with expectation (estimate) of some value in return.
Let's start with a core principle of all project work, and possibly a principle of all life's work when we encounter money.
We can't determine what something is worth until we know what it costs.
This is a crass capitalist point of view I know. But we live in a crass capitalist society and them's the rules. Don't like the rules, it might be better to look somewhere else for work other than spending other peoples money without knowing how much it will cost in the end and when we'll be done.
We all know and maybe even experience a Dilbert's paradigm when it comes to projects. But that doesn't make it right. We hear this some times from management. But we also hear it as an excuse for not making estimates from those who should be looking after the cost needed to compute the Return on Investment.
A Few More Myths
Below are some links to other Blogs on this topic, explore, think about our role in managing other peoples money.Related articles How To Estimate Almost Any Software Deliverable Measurement of Uncertainty Credible Estimating Processes Everything is a Random Variable Estimating Accuracy
Looking back over my life, I'm reminded of many blessings, things that have shaped me, challenged me, and defined me. Sure, there are the obvious ones: My home, my family, my career.
There are more subtle points - events, opportunities, people - which played a role in my life. I may not have realized it at the time (and generally didn't), but looking back, they served a key role. Here are just a few:
Paper Route - from ages 11 through 15, I carried the Des Moines Tribune (the now defunct afternoon sister paper to the Des Moines Register). I had an average of 40 customers who expected their papers promptly, placed exactly where they wanted it. By the time I was a teenager, I had the basics of customer service and customer facing down. I learned self-discipline and responsibility. I learned to appreciate what was going on in the world (watching headlines change throughout the entire Iran Hostage crisis).
Family on the Farm - both of my mom's siblings (and their families) farmed. From birth, I was exposed to livestock and crops, to dirt and creekbeds. I listened to family discussions about market prices and government programs. I was able to experience sights and sounds and smells to instill an appreciation for nature. It's served me well in seeing the systems in the world around me and exactly how much everyting is connected.
Healthy Drama - I was a bit of a theater geek in high school and college. I got to learn from some awesome coaches and teachers about acting, creating a character, setting a mood, and appreciating really amazing writing. These opportunities shaped me as a teacher, an author, a creative, an office politics consultant, a project manager, and a dad. Always let your imagination come out to play.
Sunday School - I have pretty fond memories of my childhood church and what it represented back then. Learning Bible stories from different teachers, framing my values system, singing songs... it broke down the mysteries of religion and provided me with a framework for how I view the world. As I grew, I was able to add on to those building blocks, to interpret scripture in light of its original context and how its timelessness applies to an ever-changing world today. I'll be forever grateful to those faithful ladies and gentlemen who took the time to teach Bible stories to us kids.
Dogs - What can I say about Sam, Casey, Zorro, and now Fergus? Their love, their humor, and their needs taught me the basics and the complexities of taking care of other living beings. I observed their ability to listen. I saw them communicate without words. I viewed what excited them, what scared them, and what motivated them. Seeing the world through a dog's eyes is inspirational and honest.
So this Thanksgiving, I'll enjoy the trappings and trimmings of family and food. But I will have an eye on the past and its many blessings. Enjoy the holiday!
When we hear about software development methods, it's critical to understand in what domain they are applicable. Here's an analogy for that question. Without an answer to this question there is no basis for comparing units of measure. What might be a wonderful approach in one domain would be unusable in another - this is the case for all the examples.
A solo or 3 team project with a customer in the same building would never apply DOD 5000.02, FAR 34.2 Earned Value flow downs. Building the flight avionics to fly to ISS would never use #NoEstimates and emergent requirements on a weekly basis for a 200 person development team spread across the United States.
So before any conversation - beyond shared ancedotes and asking audiences to think about it, because I can't tell you what to do - can take palce, we need to establish the domain, the value at risk, and the governance model applied to our work. Then we can talk about shared ideas.
Paradigm of agile project management from Glen Alleman Related articles Performance Based Management It's Not the People It's the Process? Five Ways To Rethink Software Projects Agile Project Management
In my first management role, I “managed” one person. My managee didn’t need much management. He guided me into how to manage him more than I managed him. He saved me from making too many mistakes. It was great practice for me.
Later in my management career, I managed a “team” of 15 testers. They were not a team. They were a group. I’m not sure why my management insisted on referring to them as a team, but my managers did. My role was to match-make testers with projects.
I didn’t think of my role as allocating people to projects, because I kept people on projects long-term. I didn’t fall for the management myth that I could move people like they were chess pieces. That’s why I thought of my role as match-making. I managed the project portfolio for the test group, so I could match-make.
What else did I do with this group?
I’m sure there was more, but that’s what I remember now.
I recently met a smart CTO of a company with about 100 engineers. He said he wanted a flat organization. Makes sense to me. Then he said this, “Every engineering manager should be able to manage about 15-20 engineers, and the projects that they work on, too.”
Oh, boy. You will notice that I was not managing projects in my list above. I was hiring like mad, in addition to the above management responsibilities, and I was full. I could not do any more. If you’d asked Mark, I bet he would have said I was past full. I did all my phone screens after dinner. When I needed to, I also wrote reports after dinner. I had no time during the day.
Could I have done any useful project management? No. Could I have managed any more people? No. Certainly not up to 20. Why? Because I needed time to meet with everyone, some people each week.
Why could I manage 14 people? Because I was an experienced manager by this time. I’d been practicing. First with one person. Then with three or four. Then seven, eight. When I had nine people in my group, I realized I had to move to biweekly one-on-ones for some people. I asked the people who were more senior if they minded. No, it was okay. But if they were more junior and needed coaching? It would have been a disaster.
And that is the topic of this month’s management myth: You Can Manage Any Number of People as a Manager. If you don’t care how well you manage, you cannot manage any number of people and do a great job. It’s the same principle as code or projects. If you don’t care how good the code is, you can write as much as you want. If it doesn’t have to work, it doesn’t matter. If you don’t care how good your project management is, you can manage as many as you want.
I’m not talking about micromanagement. I’m talking about providing coaching if the other person wants it, a learning environment for the people, a place for people to learn, a trusting relationship with each person every week. That’s it. I expected the people in my group to spend the rest of their time learning on their own and being responsible.
But because we were hiring, and because I had responsibilities across the organization, we were all busy. If I hadn’t made time for our one-on-ones, I could have gone for weeks, not seeing people. That would have been Wrong.
If you are managing more than nine people as a manager, rethink what you can do. If you are not having one-on-ones every week or every other week, what else are you doing?
Management is not about micromanagement. It’s about creating an environment in which everyone can do their best work. If you are too busy to do that, are you really managing?
The recent post about the 5 Ways To Rethink Software Projects has elicited a response from the author stating I was being unfair to his thesis that in the end - Number 5 - we didn't need to make estimates. Of course without any domain or business processes governing the expenditure of other peoples money, it's hard to tell where the proposed ideas would fit it.
Going back to basics with the clip below, I'm reminded we seem to have lost all visibility to why estimating is needed in the first place. The clip below is from a 1970 Naval Post Graduate School (NPS) thesis about the troubles with estimating. Many of the problems are still in place today. So you may say we haven't move beyond the orginal problem. But that would be too simple. The papers below, including this 1970 thesis shows how far we have come.
I'd conjecture to move beyond twitter exchanges and interviews of personal anecdotes we need to test the notion of how to improve estimates in the market place. Anecdotes are fine, if derived from actual hands-on experience in a domain or similar domain. The bottom's up discussion many times ignores governance and simple business processes and is stuck on the you're not listening to my great idea that XP was in early on. As Carl Sagan suggests
"Extraordinary claims require extraordinary evidence." Carl Sagan
The systems referenced below are not in the domain of the CIO magazine article. But the principles for forecasting the cost of a project before - or near the start - work is still an important part of Project Governance. The notion of project governance seems to have been skipped over when we look at the problems of estimating. From the management of the ACA web site, to large ERP systems, to major weapons, to major science projects - managing the project with the paradigm of governance is actually harder than it looks. It is hard because the value at risk is more important than the interests of the individual. The subordination of self interest some times is more difficult than seeing the bigger picture of managing other peoples money.
So we can choose to explore how to improve our estimating capabilities or we can seek out ways to avoid estimating all the together. But in the end, those with the money likely want us to learn to be better estimators. We should ask them, before assuming they want us to stop estimating the cost of work - #5 in the list of ways.
That's the message here. If you have a customer who will pr ovide you with funding in the absence of knowing - in some way, with some confidence - how much it will cost in the end, I'd suggest you proceed and hope for the best.
There is a common idea found in some software places, especially one that start with the notion that we don't want to do estimating, or estimating is not needed when spending other peoples money, that estimating is hard, is the same a guessing, and produces results not valuable or not needed by the customers.
Let's start with a paradigm. If you choose to not estimate because you don't want to learn, well not much to do about that. But let's read what Barry has to say.
There is no good way to perform a software cost-benefit analysis, break-even analysis, or make-or-buy analysis without some reasonably accurate method of estimating software costs and their sensitivity to various product, project, and environmental factors.
Professional organizations for cost estimating
Ignoring for the moment the problems with the logic of ignoring the needs of those providing us money, here's some places to start in the domain where estimating is the basis of good project management
There are many more approaches. Google will get you them all. But in the end you actually have to want to learn how to do software estimating. If you start with the notion that estimates are either not needed, serve no purpose, or you simply have heard this from a source that has no connection to your domain, nor wants to - then you'll probably want to ask a few more questions:
So when you hear someone suggest we need question everything then question the questioner if he has any experience at all spending other peoples money on a project where the value at risk is substantial to the point if the project fails he'll ge fired.
No? not working in that domain - manifestly important and nearly impossible - according to Edwin Land, then that advice about estimating may be a bit too narrowly focused, limited in domain for your need. You get to decide.
But if you do maybe these will help as well
Matt Heusser's article brings up some interesting points. Let's look to see if there are any limitations from a domain or context point of view. By domain I mean, in what taxonomy are you writing software for money. By context I mean what are the constraints or governance guidelines in that domain.
1. Make the amount of money small
This is a version of time boxing. It limits the value at risk for the development process. This bounds the risk process. In exchange for the total loss of doing the wrong thing information can be found. This is also called tuition cost.
Issue: We may not have all we need to forecast the total cost and schedule. Projects in many domains aren't made up of small chunks of themselves. So we'll need to confirm that the sum of the parts results in the whole. Integration, test, verification, architecture, interface management, and many other Systems Engineering aspects need to be involved in some way.
2. Fund a pilot that delivers working software and use this model to forecast schedule
This is buying a reference class. With the reference class - all be it a class of 1 - a forecast of future cost, schedule, and technical performance. We need all three in the reference class.
Issue: this is a larger issue of Number 1. With the pilot can we be assured that work can be scaled? Verification of that will have to be part of the pilot or a follow on. Then comes the confidence intervals for how that scaling will interact with the other - yet to be developed - components of the system. Is the scaling linear, nonlinear, stochastic interactions, and a whole raft of other discoverable processes. Each needs to be planned and budgeted.The ACA web site is a recent example. A UAV I worked where the engine didn't have enough thrust after the final integration. Etc. etc.
3. Move from contract negoiation to partnership
You've simply transferred to responsibility to estimate the cost and schedule to someone else. A single example - in the article - is not the basis of a syndicatable process. So this example, while interesting, probably isn't going to go too far with someout means to address the Estimate at Complete needed in most non-trivial software development projects.
Issue: Still don't know how much the project will cost in the end.
4. Employ Start Stop Heuristics
Seems like just another version of time boxed budget and schedule.
Issue: still doesn't address the Estimate at Complete before actually reaching the end or near the end of the project.
5. Drop Estimation From Your Estimation Process All Together
Another version of time boxed budget. Someone has to know how much money is needed to run the business on an annual basis. Or how much money will be allocated to do some work on an annual basis. This is called Level of Effort. Work until the money runs out, we give you more money, or tell you to stop. PayPal works in this way - sorta. The prioritization of the work is the responsibility asking for the outcomes. They have a budget. Give that budget (not funds, budget) to the development organization in exchange for delivered code.
Issue: The project will cost a know amount. We don't know what we'll get for that amount. But that might be OK. Once work is been going for awhile, a Reference Class can be built to allow that question to be answered, assuming the requested software fits inside the reference class in some way.
So In The End
The 5 suggestions don't have a domain beyond the single examples. And the suggestions don't seem to have a way to forecast the bounds of the project with an Estimate at Completion beyond the use of the reference class of the project itself. This self referencing reference class seems a bit sporty.
So yes, there are some ways to develop software in the absence of formal estimating. Although 2 of the 5 are actually using reference classes to forecast.
Those paying for the work to be done, still have to come up with some upper bound on cost, schedule, and technical capabilities for that cost and schedule. These 5 suggestions are a start. But we don't yet know where they can be applied. If they have been applied outside of specific anecdotes, and if they are scalable beyond the personal anecdotes.
No problem. This notion of not estimating is still evolving. At some point, answers need to be forth coming and the Yoda-style conversation replaced by business conversation - what did you do with my money?
In a meeting today on the difficulties of increasing the probability of project success in our domain (DOD/NASA). There were three sources of uncertainty around cost, schedule, and technical forecasting
The program runs into things that cause cost and schdeule overruns:
We really shouldn't be doing #1 and #3. #1 means we didn't look hard enough. #3 means we can't handle the truth. #2 is the definition of uncertainty. But is it uncertainty because the project, didn't know or didn't want to know.
Doing stupid things in purposeRelated articles Reference Class Forecasting for Software Estimating Facts and Fallacies of Estimating Software Cost and Schedule Who pays? How NOT to Estimate Anything Cost (and Schedule) Estimating Foundations
From the Ask Tom mailbag -
You said yesterday, that a non-engineer can be a manager to an engineer. How could that work? I remember you said that one purpose for a manager, is to bring value to the problem solving and decision making of the team member. How can a non-engineer manager bring value to the decision making and problem solving of an engineer?
I will assume that an engineer can make decisions and solve problems that are clearly within their defined level of work, or they wouldn’t be in the role in the first place. Further, I assume the engineer may need managerial support for tough problems and tough decisions.
Your question is, how can a non-engineer manager bring value to an engineer attempting to solve a tough engineering problem?
The most effective managers are those that ask the most effective questions.
A manager does not have to be an engineer to ask these questions. Would these questions have been of value in the roll-out of a complicated website?
When managing projects that are funded by other people's money, we are obligated to know something about the probabilistic outcomes of our work. Without the ability to make forecasts and estimates of these outcomes , we are relegated to the category of labor.
As Project Managers, we must learn to estimate and forecast to some level of confidence. This is not guessing, that is child's play. Choosing not to estimate is also child's play. We must learn to make estimates based in sound statistical and probabilistic principles. Without that, the very notion of Return on Investment is intentionally ignored.
Return on Investment = (Value produced - Cost to Produce) / (Cost to Produce)
It's that simple and it's that hard. The cost and value variables are probabilistic estimates and must be treated in that way. But without knowing either of these, to some degree of confidence, we cannot make informed management decisions.
That is the primary role of project management or engineering development -
Make Decisions based on evidence in the presence of uncertainty