Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
Software Development Blogs: Programming, Software Testing, Agile Project Management
Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
This branch of mathematics [probability] is the only one, I believe, in which good writers get results entirely erroneous - Charles Sanders Pierce
When it is said -¬†you can't estimate the future - or¬†we don't know total cost, think of Mr. Pierce. All things project management are probabilistic drive by the underlying statistical processes of irreducible and reducible uncertainty. Rarely, if ever, are these uncertainties¬†Unknowable, in the mathematical sense.¬†
Here’s a problem I encounter often. A middle manager calls me, and asks for an estimation workshop. I ask about the environment. The manager tells me these things:
When the developers meet their dates but the testers never do, it’s almost always a couple of things: Schedule Chicken, or technical debt masquerading as done in a waterfall project.
If the project starts on time and it’s close, it might be an estimation problem, assuming no one is multitasking.
But if the project starts late, this is not an estimation problem. This is a cost of delay due to management indecision.
Wouldn’t it be nice if you could say,
A lack of planning on your part does not constitute an emergency on my part
to your managers? Well, just call me the Queen of the Career Limiting Conversation. This is why managers are supposed to manage the project portfolio.
When I hear the plea for the estimation workshop, it’s for these reasons:
The managers are, ahem, all tied up in their shorts. The can’t decide, which is a decision. They don’t fund the potentially transformative projects or programs. They go with the safe bets. They do the same projects over and over again.
If they get lucky, they choose a project which is small and has a chance of success.
How do you discuss this cost of delay? You ask this question:
When did you first start discussing this project as a potential project? or When did this project first go on our backlog?
That provides you the first date you need. This is your next question:
When did we actually start working on this project?
You want to see how long it takes you to consider projects. It’s okay to consider some projects for a while. The difference between the time you first start discussing a project and the time you start working on it is your management cost of delay. I just made that up. I bet there’s a real name for it.
What is the difference in those two dates?
Project lead time is the time you started discussing a potential project and the time you finished it. Project cycle time is the time you started a project and the time you finished it. Yes, we normally discuss lead time and cycle time for features. But sometimes, it makes sense for projects, too.
If you release projects, not features, and you have managers who have decision problems, they need to know about this cost of delay. Because the project lead time will take time out of your maximum revenue. The longer that lead time is, the more it will take.
The worst part is this: how much value does the project have, if the project lead time is “too long?”
What can you do?
I didn’t say it was easy. It’s healthier for your organization.
Who do you think can measure this cost of delay in your organization? What do you think might have to change to make this cost of delay visible?
In Cost of Delay: Not Shipping on Time, Part 1, I introduced you to the notion of cost of delay. I said you could reduce the cost of delay by managing your projects: have shorter projects, using release criteria, or selecting a lifecycle that manages the risk.
Sometimes, you don’t have short projects, so projects get backed up, and your managers ask you to work on several things at once. Or, the managers can’t decide which project is #1. Somehow, you end up doing several things “at once.” This is the multitasking problem, and this is the cost of delay in this part.
You know me, I hate multitasking. The costs are significant. But those are just the costs of multitasking on the work you are doing now. That has nothing to do with the cost of delay to your projects.
In Manage It!, I have this nice picture of what happens when you try to multitask between two projects.
Imagine you have two projects. Each of them should take a week. Hey, they’re short projects. I’m trying to illustrate a point.
You can deliver one of them at the end of the first week. You can deliver the second one at the end of the second week.
But, imagine you have to multitask between them. Instead of being able to deliver anything at the end of the first week, you can’t deliver anything at all until the second week. And, depending on how much context switching you do, you might not be able to deliver anything until sometime during the third week. The blue boxes show the time lost due to context switching.
This is a huge cost of delay due to multitasking.
How do you calculate this?
“Big” is not quantitative enough for some people. This is where using some of the tools from the people who do this for a living might be good.
I’ve always drawn a picture like this and explained, “I don’t know how to estimate the time in the blue boxes. The blue boxes are the delay times. I can’t estimate them, because everyone else is delayed by multitasking on their projects, too. Sometimes, it takes me an entire day to get an answer to a question that should only take me an hour to get an answer. All I know is that “ideal” time is irrelevant to actual time. And even calculating using relative estimation is hopeless. That’s because we are multitasking. All of our estimations are out the window because we are multitasking.
“The amount of time we spend working on a project might be accurate. It’s the wait time that’s killing us. I don’t know how to estimate that.”
What I’ve done before is take a two- or four-week window, and ask people to write down their predictions of what they thought some task would take. Then, I ask them to write down, as they spend their time on each task, how much time they actually spend on each task. Now you can compare the prediction to reality.
Remember that all of the context switching and wait time is the time you need to remove from the maximum sales revenue, had you released the product.
This is very difficult to do. It saps the morale of the people doing the work. They quickly realize how often they go back to the same thing, over and over and over again, making zero progress, trying to realize where they are. Do not do this for more than a four-week window. If you must do this, label this an experiment to obtain data. Explain you are trying to obtain actual work time, context switching time,¬† and wait time. Let people label the time as they will.
The managers will be astonished by how little time the technical staff spend on real work. They will be amazed by how much time the technical staff spend on context switching and wait time. This is why managers think technical staff are bad at estimation. Who can be good at estimation when they are multitasking?
The problem is this: the cost of delay due to multitasking is real. It’s invisible to most people, especially management. It’s not just the cost of the blue boxes in the picture above. It’s the fact that nothing gets out of your organization until the end of Week 2 or later. Remember the back of the napkin in Part 1? Even if you use that calculation, you can see you are losing revenue left and right due to multitasking.
Remind the managers: Remember that all of the context switching and wait time is the time you need to remove from the maximum sales revenue, had you released any of the products.
Can you use this as an argument for your managers to end the multitasking and manage the project portfolio?
Cost of delay due to multitasking is real. What would you need to know to calculate it in your organization?
Do you know about the Cost of Delay? It’s the way to think about the revenue you can lose plus the cost of continued development.
One of my managers many years ago had a back of the napkin approach to cost of delay.
“Johanna, we want to ship this product in the second quarter this year. We estimate it will take us a quarter to ramp up sales. We think there is a lifetime sales of about five years for this product. Any delays in our shipment will not push our sales figures to the right. They will remove our max sales from the middle. Got it? We have to make our ship date.”
I got it.
There weren’t too many of us developers in that organization. We all knew what our job was: to release on time, and make sure the product was usable. The product didn’t have to be perfect. The product had to be usable, because we could release fixes if we needed to, but we had to climb that sales ramp to get to that max sales point.
We worked on one project at at a time, until it was done. Then we went to the next project. We worked on that project. None of our projects was very long. Why? Because we needed to realize revenue. You can’t realize revenue with a product-in-a-box if you don’t ship it.
We didn’t ship too many fixes. Oh, not because we were perfect the first time. We asked each other for review, and we found problems, so we fixed them inside the building. Before we shipped. Because the cost of not shipping on time was too great.
When you delay your release and don’t ship on time, you miss the revenue from the maximum sales times. Take your delay in weeks, and remove the revenue weeks. That’s your cost of delay, back of the napkin approach.
You can go through more serious calculations. Troy Magennis of Focused Objective talks about a “compounding impact” on other projects. I am sure he’s correct.
But even if you said, “Every week we slip, we lose at least a week of revenue from our maximum sales week of revenue,” do you think people would notice?
How do you release on time? You fix scope (ha!). You have release criteria. You have shorter projects, because they are easier to estimate and deliver. You use an incremental or an agile lifecycle, so you have more predictability about your release.
This post is the simple idea of not shipping on time. But what about when you have competing projects and not enough people? Look for Part 2, next.
P.S. After I wrote this post, I realized I was not living this post. (Why do you think I write? It’s not just for you. It’s for me too.) I published the incomplete Essays on Estimation. I have another essay or two to release. But if I don’t release it, you can’t read it and get any value from it, can you? The point: if you don’t release your products, your customers can’t get any value. Hat Tip to @jlottsen who said in a tweet, “you have to release it, or no one can use it, and you can‚Äôt realize any revenue at all”. Very true.
I was invited to speak at an interesting company event in Gent two days ago, where I discussed running experiments with Exploration Days, Business Guilds and more. One employee asked me this interesting question:
How can the non-IT departments participate in Hack Days or Exploration Days? How can they help innovate?
Performance-Based Project Management(sm) on Amazon
Here's the Table of Contents and Chapter 2. This chapter is the anchor for the Principles, Practices, and Processes of increasing the probability of project success.
Performance-Based Project Management(sm) from Glen Alleman Here's a quick overview of the rest of the book with Principles, Practices, and Processes 5 immutable principles and 5 processes in 60 seconds from Glen Alleman On a bit more detail about how the parts all come together
Performance based planning in a nut shell (V5) from Glen Alleman ¬† ¬† Related articles Flaws and Fallacies in Statistical Thinking What is Project Management About?
Many years ago some people came up with a brilliant idea: "what if, we could turn abundant lead (Pb on the table of elements) into scarce gold?". A brilliant idea to be sure, but as we know now, impossible. What made Alchemy grow and thrive as a science, was that people at that time did not know that it was impossible. They did not have enough knowledge of chemistry to know that you cannot turn an element's atom into another element's atom. That did not stop them however! And thanks to those crazy idealists today we have Chemistry. How about that for a twist of fate?
Alchemy's history can be traced back for millennia, and that name stands as the prototypical failed science (except for poets and ‚Ä¶ idealists). Failed because it based its existence on a belief that was impossible to make reality in our world.
I find many parallels between Alchemy and Management science today. Alchemy wanted to find the magic Philosopher's Stone that could turn led into gold, Management scientists are in a similar quest: in search of the method that can make management succeed as a science. Management science's goal today is to find the magic ingredient that can give us predictability.Basic Science
Many management-fads are based on the hypothesis that you can control the world around you, mold it in a way that can give you predictability. This (mythical) predictability is a core assumption that enables the management's idea of success: I will do X so that I can achieve Y and therefore succeed.
This predictability is, however, a form of causality. Many, perhaps including you, will not think of it that way, but predictability is only present in systems where you can determine causality. A predictable world is one where we can reliably predict what happens when we do X, i.e. a world where we can establish causality.
Newton's laws gave us predictability in the physical macroscopic world of objects, because they told us what would happen if, for example, you rolled a sphere in an inclined plane, or shot a bullet from a canon, or shot an arrow with a bow. Relativity theory gave us predictability (to a certain extent) in the microscopic world of atoms, or sub-atomic particles also because it established useful and applicable causality rules
Medicine gives us (mostly) predictability in the world of diseases and biologic systems like the human body because it has a system of studying and documenting causality: if you take Aspirin after a great Saturday night party, you will feel milder effects of the oncoming hangover.
You can see why management theorists (and practitioners) would want to achieve the same goal: predictability.Predictability is management science's Philosopher's stone.
The Philosopher's stone
Planning is one of those attempts at achieving predictability. We plan, because we believe that planning will give us the predictability we seek. Without the goal of predictability we would not plan, there would be no point.
But planning itself rests on the assumption that we can predict (here it comes again) causality in the world where the plan is to be executed. If we did not believe that we could predict B to happen after doing A, then planning would not be possible. It would be illogical.We plan to be able to predict, but plans only work if we can predict in the first place!
The problem with what is stated above is that it is a circular dependency: we plan to be able to predict, but the act of planing rests on the assumption that the world is predictable. You see where this is going, right?
The sad fact is that there are many other management techniques that both rest on, and try to achieve predictability. For example: pay for performance, management by objectives, or the yearly strategic plan.Going around in circles
All these management techniques have one thing in common. They are static. They exist at a precise point in time: Strategy is defined in the Spring or Autumn and is supposed to be executed for the next 12, 18, 24 or more months. Objectives or goals upon which our evaluation is based are set several months in advance of the point of evaluation.
All these techniques require perfect, 20/20 foresight. How likely is that?
The basic problem with most perspectives on management today is that they are static analyses of a future environment. And all decisions are made because we believe we can predict the future.
We make these predictions to help our businesses be more predictable, but our predictions depend on our business being predictable. This circular dependency is why most management approaches are doomed to failure. Like Alchemy.Looking forward
We need a new Management Science, one that does not require the existence of a predictable world. When it defines goals, it does so in a way that is dynamic, i.e. the goals change with the observation of reality. This dynamic adaptation process is what we, in the Agile community, call a feedback loop.
A future-proof management approach must start by basing it's core assumptions on the existence of feedback loops that must be studied and tested as we make decisions. And these feedback loops must be the driving factors for action in management. Not the plans!How would such a management approach look like?
The first assumption of such a management approach must be that the world is not predictable beyond a very short time. This may be a simple statement, but the consequences of this simple statement are fundamental.
What would your world look like if you believed and followed the three principles above? How would it differ from your current perspective on management?
Image credit: John Hammink, follow him on twitter.
I have two major weaknesses. (Well, actually many more, but this should be a blog post, not a book.) My first weakness is I hate sports. Or more generally, any kind of strenuous activity. A good walk is fine, if not much longer than 2 hours, thank-you.
The processes by which we have discussions about project processes must be based on probability and statisics. Every project is subject to aleatory (irreducible) and epistemic (reducible) uncertainties. When we talk about cost, schedule, and technical performance are all statistical in nature.¬†
Here's a book that should be read before engaging anyone in a conversation about the processes of project management, estimating, risk, performance management.
Some of the most hilarious scenes in the Pixar movie Finding Nemo involve a flock of seagulls yelling ‚ÄúMine! Mine! Mine!‚ÄĚ every time they see something they want for themselves. I thought back to those movie scenes several times in the past few days.
There’s a great comment to my recent Management Myth: Performance Reviews Are Useful. The writer has these questions, which I have paraphrased:
1. How do bonuses work?
Here’s the problem with bonuses in a team-based organization (agile or not). How can you tell who has done which work? Who actually knows who has contributed what?
The team does. This is true whether the team is agile or not. The team always knows who has done great work, who has pulled done whatever, or if someone is hiding. It’s easier to know if someone is hiding in agile.
The team always knows who has done what. The manager can try to know, by asking for status. The manager can try to know by asking for accomplishments. But the team knows.
That’s the first problem.
The second problem is why is any knowledge worker’s pay based on a bonus? This smacks of management by objectives. You know the kind, “We’ll increase our sales by x% over this year.” All other objectives flow from that. By the time they get to you, your bonus is supposed to be based on you completing a specific project your managers were supposed to fund at the beginning of the year.
Did you read all of those “supposed to” in the previous paragraph? That’s what happens with traditional project portfolio management and big-bang funding. That’s part of the reason you end up with multitasking which makes everyone crazy. People are trying like crazy to fulfill their personal bonuses (optimizing at the lower levels) instead of doing what the organization needs. This is one of the reasons I wrote Manage Your Project Portfolio.
How many of you missed out on a bonus because some salesperson screwed up? (My hand is up.) We completed our technical projects. Sales sold stuff we didn’t have. Sales didn’t sell stuff we did have. Management didn’t decide on a reasonable strategy, even though we completed our projects. Somehow this was our fault as technical people? Come on. We did our parts. No bonus for us. This is fair? Nope.
When you provide individual bonuses, you do not guarantee better results. We have data that proves this. Read Dan Pink’s Drive: The Surprising Truth About What Motivates Us, Pfeffer & Sutton’s Hard Facts, Dangerous Half-Truths, and Total Nonsense: Profiting from Evidence-based Management, and Hope’s Beyond Budgeting: How Managers Can Break Free from the Annual Performance Trap.
If your company is basing your compensation partly on bonus, it’s because they are cheap. They are trying to tie part of your compensation to something you have no control over: revenue. Revenue sharing is fine for retirement funding. Not so fine for regular compensation.
2. How can a company know who is contributing and who isn’t?
Ask the team. They know. Who else needs to know and why?
This is why you want to push the responsibility for feedback and coaching into the team. This is why you want the manager to be a servant leader.
When the manager is a command-and-control leader, no one knows nothing.
Why would anyone step forward and take responsibility? It is no one’s interest to do so.
3. Without paperwork we introduce possibilities of lawsuits, particularly for big companies? ¬†If a man is paid less than a woman and it is found out, using your logic, discrimination lawsuits are reasonable since there is no ranking. ¬†HR likes this paperwork to try to protect the corp. ¬†Granted Netflix has a solution of 6 months severance, but do you have any other alternatives?
Let me separate this one. You don’t need paperwork to know if people are paid comparably.
You can have salary ranges for each level. You can group each level and see what you get. I did this at one of my jobs. I discovered that when I was the only female manager, I was the¬† one paid $10k less than the men. I brought that to my manager’s attention. He hemmed and hawed. I persisted. I said the word “discrimination.” They gave me a raise to bring me parity.
I wasn’t ranked. I grouped people by salary range, that’s all. I didn’t need ranking to see this. I needed a spreadsheet.
I hadn’t done this to look at my salary by the way. I had done this to look at all of Engineering, at the request of my boss. The question is this: What problem are you trying to solve?
HR doesn’t need ranking. They need common sense, which I admit, isn’t all that common.
Paperwork doesn’t solve problems. Paperwork protects HR from lawsuits, maybe. My paperwork proved that the company was discriminating against me. I didn’t intend it that way. But that’s what it proved.
4. You are arguing that management doesn’t need to exist in the traditional sense (since paperwork has been a big part of the job). ¬†If agile has killed the ability of the manager to know what is going on and can’t review the employees, why have a manager at all? ¬†Why not replace people-oriented managers with project-oriented managers?
Managers exist to create an environment that helps people do their best job. Managers exist to create and refine the strategy and to organize with purpose. Managers provide coaching and meta feedback. Managers initiate communities of practice. Managers manage the project portfolio. Managers provide servant leadership.
Even if managers did performance reviews, they didn’t do reviews every day of the year. They didn’t rank every day of the year. They certainly didn’t keep their eyes on “their” employees every day of the year. (Okay, the micromanagers did. But most traditional managers were not micromanagers. They were poor lost souls who didn’t know what else they should be doing.)
Project managers help a project get to done. People managers should not interfere with that. In a matrix organization, that is precisely what happens. I’m not sure what happens where you are.
I have a coaching client where the people managers are the project managers. They are also doing a form of agile. It’s their form of agile. You wouldn’t recognize it as by-the-book anything. But, because the VP is in charge of all of Engineering, he can see when the system is working and when it isn’t.
We had a conversation last year, and I suggested their stories were too big. It was too difficult for the managers to make project portfolio decisions. It looked as if some people were slacking off and some were working very hard. I suggested my coachee might not have enough data.
“If you make the stories smaller and the work flows through all the teams more evenly, you won’t need as many experts. The teams will be able to complete their work, and be able to finish their work more reliably. You will have more data on the teams. They will have more data on each other. You won’t have to pluck people and move them from project to project, which makes things worse. Before you decide some people are better or worse, why not try improving the system, first?”
They decided to do that. It was quite difficult for them. It went against everything they knew how to do: architecture, estimation, planning, implementation, everything. But they decided to try. Their managers were also their project managers and guided the teams to success. My coachee, the VP, learned that the people he had thought were great were good, but there were some shining stars he had not known about. The shining stars kept their mouths shut and kept the company running. All invisible work to the VP. Not invisible to the project managers. Who happened to also be the people managers.
There is no Right Way to organize. There is no One Right Way to manage. I lean towards servant leadership, because I don’t see how to have an effective organization without it.
How can we expect people, who are responsible adults, who have mortgages, children, and enter into contracts every day of their adult lives to turn off their brains at work? Why would we want them to?
Managing knowledge workers is not trivial. You try something, you get some feedback.
But performance reviews and especially ranking? No. Give me feedback on my work on a regular basis. Not performance reviews. Not paperwork. Not ranking. Don’t compare to other people. Tell me when I’ve done something useful. Tell me when I’ve done something not as useful, and why.
What do you think about these four points, especially about the role of the manager?
I organized a virtual drink on Google Hangouts! We chatted about quitting jobs, raising kids, consultants selling tools, best movies, watching TV, and learning Spanish.
It is no secret that I love planning. I'm not coming out of the closet now, that's been true forever! And at some point in my life I was even "cool" with that.
Additionally, I want you to know (although you will not yet understand why) that I still love planning. That's me :) Now pay attention, I'm about to shoot myself in the foot.Loading the gun
When I was in college there was a topic that I loved, the topic was Information Theory. There's so much stuff in that area of research that I can't even begin to touch the tip of the proverbial iceberg, so I'll just say - for now - that information theory is an area of research that investigates information and how it is codified. For example: how do I compress a text file? Turns out, text can be very efficiently compressed. Perhaps the blog post you are reading can be codified in a few hundred bytes. The cool thing is why that happens: redundancy. Redundancy is an unappreciated quality of all systems.
So unappreciated in fact, that we all praise it's mirror twin: efficiency. A compressed text file is very efficient (i.e. it codifies a lot of information in a very small amount of disk space - I could probably compress this post into 140 bytes and tweet it out - that would be efficient).
If we can create so efficient representation of information why would we stick the old-skool inefficient representation (for example: language)? I'm glad you ask! The reason is that language with all its redundancy is easy to understand even if you cut parts out or mangle the letters. Try reading the following paragraph (click for a larger version):
Did you understand what that said? Of course you did! Redundancy saves the day! Yay!Now about software and organizations
In organizations and companies, we also have redundancy - plenty of it! And just as well, because without it most companies and organizations would stop working altogether. Redundancy gives us resilience! Just like in the language example above: even with parts of the words cut out of the phrase you were able to understand it! And this is just how organizations work: through, and thanks to, redundancy. This is the reason why some "downsizing" efforts end up killing whole companies, and the often touted "efficiencies" or "synergies" leaders try to gain from mergers and acquisitions end up destroying economic value more often than they create. The trick with redundancy is to repeat
By now you probably agree that redundancy is good - and it is. But how do you apply it to your organization and processes?
Before we go there, we have to tackle a very neat concept of mathematics. Fractals. Fractals have a property that is mind-boggling. Fractals are concepts that once explored end up generating infinite (yes, infinite!) information. In fact, a fractal line has infinite length even while fitting in a finite space! I won't bore you with the math details, but check this page on Wikipedia about the length of the British coast line - it has a neat demonstration of how a finite space can hold a line of infinite length.
This means that fractals are generative when it comes to information: they generate infinite amounts of information. And this happens to be a very useful property to have in mind when we explore how organizations work.Making the case for infinity (and beyond)
In this post I argued that removing rules from your company's process book is actually better for your business and for your teams. The next step is to remove as many rules as you can, so that you end up with a small and simple set of generative rules - just like a fractal. Fractals are very simple equations that have in themselves an infinite number of solutions. And that's exactly what our processes should be: a small set of rules that, once in use, accommodate an infinite amount of possible behaviors - this is what I mean by "complex behavior" in the post on disciplined organizations.Conclusion
Turns out fractals are perfect (yes, perfect - as in perfectly efficient) compression algorithms: a simple equation can be solved in an infinite number of ways, which when plotted in 2D or even 3D generate an infinite line in a finite space.
This property is extremely useful when applied to processes in your company because you cannot predict how people should behave in the future, but you can create an environment that - just like a fractal - allows every actor / person in the company to act in an infinite (and therefore practically unpredictable) number of ways and adapt to whatever the ever changing reality throws at them.
If you believe that your business environment is constantly changing, and that your organization is akin to a living organism you have to embrace the concept of fractal organizations.
Fractals work for you when they allow your blood vessels to reach every cell of your body (within a few cells distance), and when they allow your brain to store vast quantities of information even if it is small enough to fit in your head. Fractal organizations are organizations that can adapt in an infinite number of ways in response to an unpredictable environment.If change is the only constant, how do I adapt to that? Epilogue
Before we can understand how to apply the concept of fractal organizations and benefit from that, a very serious question must be answered: If people can behave in infinitely different ways, how do we prevent organizations from turning into chaos? That's a question we will explore soon - stay tuned! :)Title image credit: John Hammink, follow him on twitter.
The experiment I‚Äôve been running lately is making YouTube videos, called 15 Minutes on Air. The purpose of these videos is to see if I can reach an audience of people who normally don‚Äôt read.
Sometimes you don’t need statistics.
Sometimes you don’t need retrospectives.
Sometimes you don’t need superlatives.
Software development ranges from straight forward, with small a team with a continuous improvement effort. Say a web site or warehouse management application were the customer is happy to just keep the improvements coming. Every improvement or new feature can be put to use. Along the way new ideas enter into the mix and since there is no real¬†deadline, the features can be deployed when they are ready.
On the other end of this wide spectrum of projects is the mission critical, business critical project. For example a Mergers and Acquisition strategy of two large firms that need to¬†join their ERP systems before any benefits from the merger for the customers, operations, and cash flow can be realized. Below is an example of the¬†Plan for such a project.
The first thing to put to rest is the naive and misinformed notion that planning is somehow not needed. The¬†Plan above is a strategy for the integration of legacy systems with a new ERP system. The¬†Planned date for this system is tied to business success. Long before this Plan was developed, the business strategy identified the needed capabilities of the integrated system, the planned savings from the integrated system, and a customer facing set of¬†abilities of the result.¬†
This is the fundamental Return on Investment equation. ROI = (Value - Cost)/Cost. We know the value, since the analysis of the value of the integrated system was done before the merger. The cost was estimated at the highest level from experience of integrating ERP in the past. Details come next, usually after the merger.¬†
Each of the¬†boxes provides a needed capability. End¬†box is an incremental deployment of this capability, with feedback that informs the downstream capabilities. No project can have an end-to-end detailed schedule with any hope of that schedule remaining intact. But the¬†Plan above describes the order of delivery of the needed capabilities. These are not arbitrary, these are not random, these are not subject to change. At least not without understanding the impact on the business merger process and the resulting cost savings and cash flow generation.
So What's The Point
If the¬†value at risk is sufficient to call into question business failure, or at least major issues, if the project fails to meet its goals, then we need a Plan, an estimated cost, and an estimated delivery date. To ignore these business needs is to ignore the obligation to provide that needed information.¬†
You project may not be a merger of two multi-billion dollar firms. But the question isn't¬†when to estimate but¬†when do we no need to estimate. The asnswer to that starts with the¬†Value at Risk. The business providing the funding gets to say what the value is.¬†
What is the business willing to¬†Risk on the project without knowing that value before starting?
Johanna Rothman is the author of Hiring Geeks that Fit, Manage Your Project Portfolio, and many other books. I asked Johanna three questions.
The post Management and Task-Switching – 15 Minutes on Air with Johanna Rothman appeared first on NOOP.NL.