BADASS Scale for Project Assessment

Bruce's Analysis, Deployment, and Solution Status (BADASS) Scale

It is nice to have scales to describe something in a shorthand that is common to all participants. Oldies but goodies include pH, Richter, and Saffir-Simpson.

Here is the scale that I've been using for many years in my cramped little head...but now it's going to be a thing.

The BADASS scale is very simple but will save a ton of time when trying to communicate the status of a software project (or potential project) to your technical managers. The most common question is "How long will X take?" or "When will X be ready to ship?" but that skips the most important part - a common understanding not just of the requirements but where we stand as an organization relative to the requirements in terms of experience and skill.

This scale can be used for things other than software development including sports, parenting, and construction, but without further ado, I'll discuss it only in terms of software development.

We'll start with the extreme negative end of the scale:

Minus Four (-4)

• Might be theoretically impossible (i.e. defies known laws of physics, economics, etc.)

MinusThree (-3)

• This idea is a Bermuda Triangle. Every company that has tried it has ended up in a watery grave, and we have no reason to believe we'll be any different.

MinusTwo (-2)

• We don't know of anyone who has ever succeeded, and we know some people have failed at similar things, but we don't know that this has ever been tried precisely. It doesn't seem that impossible, and we have some expertise that others who attempted it might not have.

Minus One (-1)

• Preliminary indications are that, while it hasn't been proven, it certainly sounds feasible, and we are relatively confident we can succeed if we devote sufficient resources to it.

Zero (0)

• We know others have done similar or identical things, or preliminary research confirms it is indeed feasible. We haven't done it yet, but we know it can be done by the team we have.

Zero Point Five (0.5)

• We have done this, or something highly similar, at least once. What he have so far is just a proof-of-concept (POC) or perhaps a rough beta version. There are no known obstacles that would prevent completion, but there is still some work to do to ready it for internal release, much less public consumption.

Plus One (+1)

• We have solved the problem and implemented a solution but it is still "version 1" of the product. We may have hard-coded some things to get it working, so it isn't necessarily elegant or scalable. We probably need to do some refactoring. We have only done this for one client, with limited scope, so other future clients may need further customization or flexibility. We anticipated what we could, but, with a limited data set, we didn't put in every bell and whistle. There's still a lot of work to do, and we've incurred some tech debt along the way, so it is still a bit early to celebrate. We still have no ability to customize it for different clients rapidly. If you are going to sell the hell out of this solution, we'll need some lead time to ramp up.

Plus Two (+2)

• We have a solid version 1.1 (maintenance release) and are well on our way to version 2. We've released the software for at least two clients, so we've worked out some of the kinks and eliminated some hard-coded stuff. We have proven that we can distribute a single piece of software with sufficient configurability that it can be used by two somewhat different clients (i..e, support skinning, etc.). We are starting to feel confident about software but awaiting feedback from customers, etc. We're not out of the woods but we can see a clearing up ahead.

Plus Three (+3)

• We have released at least version 1.5 and more likely version 2. We have a handful of clients using the software. We've proven that everything works as intended, and there is sufficient flexibility that we can customize it in a reasonable time for a new client. Suppose it took six months to develop the software, but we can customize it for a new client in less than, say, a week, preferably a day or two. We're still cleaning up some tech debt and doing ongoing QA, but it looks like all systems are go for limited scale. The number of unique requests from customers has begun to trail off, so we are 95% confident that new customers won't have unique requests we've yet to account for.

Plus Four (+4)

• We have released the software for at least a dozen clients. We have proven that there is minimal to no "hand-work" that needs to be done for a new client. Set up is smooth and reliable, and mostly automated. We've proven we have sufficient hardware, software, and support resources. The Help system is functional; there is documentation. We are confident we can scale by another 10X factor without adversely impacting other deliverables, reliability, etc. We are 99% confident that we can sell to the target market without having to do custom development for a new client. Our architecture is proven. We have monitoring in place to account for any contingencies.

Plus Five (+5)

• We have had the software in the field for a substantial period of time. Operations are running smoothly. We have scaled it massively (100x or 1000x or 1,000,000x original scale), and we have all the hardware and software needs in place. We have disaster contingency plans, 24/7 support, five nines (99.999%) reliability, etc. Everything is automated and operating like a well-oiled machine. If our lead developer quits tomorrow, we won't miss a beat.

 

Some Sample Conversations

 

So, let's imagine how easy conversations can be between people who understand this scale compared to people who do not.

By analogy, let's assume we have two people talking about the weather. Here is the conversation:

"Wow, it is 34 degrees out!"
"I better get my coat and scarf!"
"Are you crazy, you'll need a bathing suit and sunglasses!"
"I thought you said it was 34 degrees!???"
"Centrigrade, dude."
"Oh, I thought you meant Fahrenheit."

How many conversations have you had that go like this:

Developer: "Okay, we're done with Appliances Unlimited's installation. I need a break."

Manager: "Great, we need to release the software to Mega Dept. Store on Monday."

Developer: "Whaaaat? We've only just released a prototype to Appliances Unlimited!"

Manager: "So, it's the same thing, right?"

Developer: "Well, no. We cut a lot of corners, have to do a lot of things by hand, and won't be ready to release it to another client for a month."

Manager: "But we've already been working on the software for six months. Why didn't you tell me this was an issue?"

Developer: "This is the first I've even heard about Mega Dept. Store. Why didn't you tell me we had sold another client the software? I didn't even know we gave them a demo."

Manager: "Why didn't you tell me that the software wasn't that flexible?"

(Curtain)

BADASS to the Rescue

 

Now, let's imagine what would happen if everyone had a common understanding of the BADASS scale.

Developer: (when the project starts) - "Wow, this is a 'minus two' if I ever saw one." (There could be substantial roadblocks, possible fatal ones. There are a lot of unknowns.)

Manager: "Do you think it is a 'minus three'?" (Thanks for letting me know it has a lot of risk. Are we screwed?)

Developer: "No, but I'll need to so some research." (I need more time to answer.)

Manager: "Okay, let me know if you think it is a 'minus one'." (Let me know it is achievable.)

(A week passes)

Developer: "Okay, good news, it is a 'minus one' or possibly a 'zero'. I think can get get it to a 'zero point five' in three weeks." (It has been proven, but we haven't done it yet.)

Manager: "Great, I'll start laying the groundwork for resources." (Good news, but I realize we still have a long way to go and haven't really written any software yet.)

(Three weeks pass, and there is a status meeting)

Developer: "Okay, this is a good solid 'zero point five.' What else is on the horizon, and when do we need to get it to a 'plus one'?" (I have a proof-of-concept, but it isn't ready for prime time, so don't promise too much to anyone yet.)

Manager: "We've promised the initial delivery to Appliances Unlimited in six weeks. We've communicated that this is still version 1 of a new product and won't have all the modules, right away. What is realistic to deliver in the first wave?" (I understand that version 1 always entails unknowns and risks, so what can we cut back on? I know Rome wasn't built in a day.)

Developer: "Let's deliver modules 1, 2, 3, 4, and 6. We'll leave module 5 for some future release." (Agreed, Rome wasn't built in a day, but as long as you understand where we stand, I'll do my best to help meet the business needs.)

Manager: "Okay, we need to be at 'plus one' by June 1st, so we can deliver it this quarter." (I'm getting pressure to deliver software that the customer will approve and pay for. We can't deliver a beta and expect to be paid for it.)

(Two months pass, during which software has been delivered)

Manager: "We're in talks with Mega Dept. Store, are we at 'plus two' yet?" (I realize I'm jumping the gun a bit here, but I wanted to give you a heads up. Are we at all close to having this project ready for a second customer?)

Developer: "Well, we're at about 'plus one-point-five' but I'm confident we can get to 'plus two' in short order." (Thanks for understanding that there is a lot to account for with each new customer, especially at this early stage. I'll do my best.)

Manager: "Okay, is three weeks realistic?" (We really will tank as a company if we don't get revenue soon. How hard can I push you?)

Developer: "Let's make it four weeks to give a little breathing room." (Pretty hard, but there is a lot of work to do.)

Manager: "Well, the pipeline looks good for Q3 and early Q4, we have to plan to be at a 'plus three' by November." (You need to be thinking about automation and scalability. If we can't scale, we fail.)

Developer: "I think we can be at a 'plus three' in late October, but automation will take at least until January, so let's target being at a 'plus four' by February." (I've been thinking about automation all along, but we're still putting in new features for each customer. We should be in the steady state soon as far as product development, but we need to work a lot on process, support, automation, and monitoring.)

Manager: "Okay, let's have a status check every two weeks to keep on track." (Yep, I appreciate that. Let's keep talking so we can make plans as to schedules, scope, resources, etc. I know that the software is "done" in some sense, but there is still a ton of work to do.)

(Curtain)

Conclusion

There is a tendency, when you are on the hook to do the work, to think that your manager is being unreasonable or unfair. More often than not, the manager simply doesn't understand the scope of the "plumbing" that goes into a software product.

Imagine someone is buying (or selling) a home.

Do they mention the excellent plumbing, electrical, and insulation?

No. If they can't see it, then they probably don't think about it very often.

What can your manager "see" about your software project? Probably almost nothing. Chances are, they have never even launched the software and clicked through the options. That is someone else's job. (Your manager is spending all her/his time worrying about sales and keeping the company solvent.)

How can you give your manager insight into the software development process?

The answer is "Understand that s/he doesn't care. You need to translate it into things they care about."

They generally care about schedules, expenses, resourcing, support, and deliverables.

So, until you have a common understanding about what is in a deliverable, and how different stages of software development have different needs and obligations, you won't be on the same page about the other things (expense, time, resources, etc.)

It is your job to teach your manager about the things in the BADASS scale above. If you haven't done that, then it is your responsibility to educate the manager and improve communication.

Be sure to share, link, comment, etc., and read more of the great posts on the right-hand side.

Happy coding!