IT Effectiveness

Can Do vs. Should Do

By
2 Minute Read
We live in an exciting time. We live in an era where most of what we dream up, can be created. But therein lies the rub: how do we distinguish between “can do” and “should do.” Just because we can do something, doesn’t mean it should be done.
 
Here’s our checklist for determining if something should be done… just because it can be done.
 
Outcome-based
You’ll hear this a lot from WholeStack Solutions. We are outcome-driven. We define the outcome first when deciding whether or not to take on a task, activity, or project. Defining the outcome helps us determine if something “should be” done.
We have an incredibly talented, intelligent team. When a customer asks us if we can do a thing, the answer is always, “Yes, of course.” We can do a myriad of things. But we begin working with customers to determine if the thing they are asking us to do should be done based upon the outcome they are looking for.

Why?

One of the best tools in our belt isn’t our years and years of experience or our whiz-bang technical expertise. It’s one word: why. This single question helps customers understand whether or not a thing should be done.
 
Re-invention
 
Chances are, most advertisements you experience in print, online, radio, or other formats have at least a handful of products that scream out about their “new” product. In the battle of can do vs. should do, we are often faced with the issue of “re-invention.” This is also known as “new-car-syndrome.”
You know new-car-syndrome, it’s where someone buys a new car just to get that new car smell. How often have you had a customer asking for a project simply because the current solution is “a few years old.” As you dig into the request, you find out– there’s nothing wrong with the current solution! Re-invention typically falls in to the “could do” category.

The Cool Factor

Often, when we’re discussing a project we generate a laundry list of items that we “could do.” But as we begin to think about the solution and if it’s a solution that lends itself to long term growth…we realize these “could do” features aren’t really usable. Sure, they are cool, but they aren’t necessary. As you look at your own projects, listen for comments around “cool.” Many times those will be areas to discover if there is a gap between “could do” and “should do.”
 
Why Does It Matter?
Why does differentiating between “could do” and “should do” matter? One of the hardest jobs a CIO or IT Director is tasked with is raising the return on IT investments. Helping your internal customers understand the difference between “could do” and “should do” IT projects will help you accomplish this critical task.
 
What Your IT Department Can Learn from Shark Tank
Why Your Engineers Never Have Enough Time In Their Workday