When you (as a company/organization/department/whatever) have an idea or a need or a problem you want to solve you may not have the ability to materialize the idea or solve the need/problem. You then need an ability to do it - a capability. That's the definition of "capability" I'd like to use when it comes to software (or IT in general).
If a company have an idea/problem/need that might result in them wanting some kind of capability that requires software.
Now, they want to know what that capability (via software) is going to cost them to get and maybe they need it at a specific date or at least when to expect to have their new capability ready. Nothing strange, who wouldn't?
The software is built. It might unfortunately be over budget (underestimated obviously), late (underestimated obviously) or it didn't provide the capability they needed.
But, I say it really doesn't have to matter. At least why it is a "fail". Maybe it's on (or below?) budget, on time (or maybe early?) and the right capability was provided and it still is a "fail". Why? Because the idea wasn't that good or the need wasn't really something someone actually had or solving the problem didn't really mattered.
So, how can you know before you have the capability? Well, you can't. The only way to know is to actually have it. But. There's a mind shift here. (Some are actually already doing this) Validate. At the end of the day it's all about learning. You want to learn that your idea is good or that the need is actually a need someone has or that solving a problem is worthwhile. And eventually you *will* learn (or not, if you choose not to do it).
And you can only *assume* that the capability will give you that learning.
Now, you can either start thinking about it (analyzing) or you can start acting, creating. That's the mind shift. I'm not saying: Stop thinking! Stop analyzing! But instead of "Let's postpone this to next meeting" (or whatever), think "What can we do today/tomorrow that will bring us learning about this? Is there anything small we can start doing?". I.e. how can we try - and validate - this assumption we have? Anything? Think "small". Think "learn". Think "validate".
If I take it to the extreme, I basically think they have two options (according to The Rule of Three they should have three options and not two, because 1 option is a trap, 2 is a dilemma, 3 is a choice :-) - heard through George Dinwiddie and Jerry Weinberg. But I'll let you ponder on that third option yourself. Or let all the "gray zones" in between these two extremes be those options).
1. Assume there's a software project ahead and start defining it. Gathering requirements, start planning, estimating etc.
2. Assume there's something small that can be started now (or as soon as possible). With the focus on validating that the assumptions are correct. Maybe we can continue iterating from there or at least we are more confident (validated) that the capability will make a difference and can go to point 1 above.
I'm not saying some (most?) companies aren't doing this already. But this is my experience, and the customers/companies I've met don't have much of this mindset. Your experience may differ.
And I suggest that if you have validated that the basic idea or need or problem will "pay off" it might not matter that much if project is over-budget and/or late? It's never something good, I admit that, but we might not consider it a "fail"?
But then again, it feels good being able to "blame" the IT project (and probably the "supplier" - someone else!) for being the "failure" instead of trying to change your own behaviors, seeing your own responsibility..?
The notion that the over budget and late is because of estimating cannot be true without determining the root cause of the over budget and lateness. Many thing can cause this. Assuming it is because of estimating.
ReplyDeleteYou've also not defined in what context this project is being executed. You use the term "small" with a unit of measure. How small is small. What's the value at risk if you were to run over budget or show up late? Not providing the needed capabilities may be a cause for failure but there are many more including market forces, economic forces. With a root cause again, suggesting this to simple.
Your conjecture that you can’t determine what to do with a capability until you have is also flawed. The purpose of Capabilities Based Planning is to assess how the needed capabilities will applied to the business problem and their financial and operational impacts. Please start with http://www.slideshare.net/galleman/capabilities-based-planning-v2
So your statement “How can we know before we have the capability? Well, we can’t” ignores the entire discipline in Enterprise IT of planning using one of many tools. One very useful one is Balance Scorecard. Please read this to see how BSC is used in planning IT projects http://www.slideshare.net/galleman/notes-on-balanced-scorecard
The project domain you describe is likely small, experimental, of low risk, and likely of equivalent value – “value at risk” is acceptable to not know the value or the cost before starting.
No problem, with that domain established, no estimating is needed.
The approach you are suggesting will have little value once the “value at risk” reaches the point that management can’t afford to take a risk on your simple approach. That’s is “it’s a non-starter in any enterprise level IT domain.”
This is why it is critically important to establish the domain before making any suggestions about a process. Without this established domain, any suggestions can’t be tested for their credibility.