You wrote “regarding”, and nothing else, at the end of your reply. Should I expect more comments on my comments?

The point that I want to address especially is that we can’t rely on brain cells for any of this. I would say most programmers, analysts, and business people are pretty smart. One of the problems we have is thinking that just because we are smart, we are going to come up with alignment.

It’s more realistic to think that in addition to being smart, we also need to have specific tools and processes in place, as well as common expectations about using the tools. It’s ok to capture an idea on a napkin in crayon, let’s just remember that it’s not a requirement until it’s formulated as a discrete, testable unit.

Regarding the shape, you are absolutely right: reality is a lot less symmetrical!

Regarding the task of trying to customize software that was built to be off-the-shelf, I really feel for you. That definitely falls under a mis-match between the adoption strategy and the software delivery strategy. That would probably be a useful article in and of itself. I wonder if you’d be willing to tell more? Perhaps you could be a “guest” contributor?

I am going to go against my better judgement and think about work when I should be relaxing at home. And for good reason. I think your two last posts have combined to make some pretty strong arguments about software development. You asked for stories in your last post, and I failed to give you any story, choosing rather to discuss nuance, as you put it.

Well, with this article, I am compelled to rectify that decision.

It’s funny, as a developer myself, one would think that I have the brain cells to realize the gaps that you are talking about, so that when I have a vendor develop software, I know the importance of requirements gathering. But it is really hard to wear two hats at once, isn’t it? One inevitably falls off.

As a developer, gathering user data from user interviews proves especially difficult when the users are so used to the “now solution” that they can’t really see the “possible solution”. There have been plenty of times when I have asked users what would make the product better, the sky’s the limit, etc., only to go back to my desk and realize they users will get whatever I create myself, because all I have in my notes is “change would be great”, without anything to follow up with.

I have also received requirements scribbled in crayon on a bar napkin. I’m not kidding.

However, as the user, I have not only asked for XYand Z, but the entire alphabet of requirements, only to be amazed at the end if it that a requirement asked for was forgotten because it wasn’t written down, even though I preached the need for it multiple times, etc.

Where it gets really tricky, and where your previous post comes to play, is when what you buy has a cookie cutter application, with only minimal development at worse, or minor tweaks at best, to customize it for the business needs. This in a way is worse than starting from scratch, because while it was purchased for what it has, it inevitably gives you countless headaches for its limitations.

I have definitely learned this first hand.

I have one other “shape” for you in this continuum. How about a light green circle in a dark blue square in a light blue trapezoid? The trapezoid signifies a documents gathering that is completely unexpected and unclear, which could be because the users don’t really even know what they want, or the developers don’t really understand the relationships that are needed within the overall structure.

What do you think?

I like your attention to nuance. I thought I was choosing my words carefully to make sure I didn’t say “cheapest,” but I think you are absolutely right. Given that the default interpretation of “cost effective” as “cheap,” I think you are dead on. Thanks for the comment!

“…what is the most cost effective means to achieve a business end?”

I would like to challenge that assumption, albeit slightly. I am arguing about semantics here, but the distinction may be an important one.

Perhaps the fundamental concern is how does a company achieve its business end with the most cost-effective solution?

This small switch of wording highlights the priority — the ultimate goal is to find a software solution that gets the job done for the company, regardless of price, but once you have your eyes set on your options for this, then you find the cheapest solution. If “cheapest” is your first priority, then you end up cutting corners, and perhaps compromising productivity.

I also really like the “adopt” term — my company will be adopting the newest version of Quickbooks in the near future. What the term does is sort of make the process more human — perhaps because “adopt” has the obvious meaning of one method for raising children. It makes the software you choose a little more significant, in that you don’t want to choose just any software, and you want it to fit in the “family dynamic” of the organization. It’s a sort of appendix to chapter four of ASAE’s “Seven Measures of Success”.

I agree! Having the positive attitude I believe is required for success. How can one succeed in a project if they don’t think it will work? I say to my sons almost daily, “if you think you won’t like that vegetable, you won’t!”

When managing projects where I don’t have a lot of say in the product (just the process), I use the term “cautiously optimistic” when the outcome truly is unknowable. I am an optimistic person by nature, but I have also been “taken for a ride”. This doesn’t make me cynical, only cautious.

When it comes to miracles, I believe in them 100%. But I do not refer to the miracles of the new testament, I refer to the everyday miracles; and yes, I believe humankind is powerful enough to steer a project to the miraculous. It is when we take things for granted that miracles do not occur. When we become complacent, as you say, miracles won’t happen. I do think they are in our control.

You provided a bullet-point of so many requirements for making a software project successful; one could look at that and say, “It’s gonna take a miracle!” And they would be right. But the miracle comes from the one who says it.

Word creates world.

It’s great to see comments from people who actually care about language. I’m a little daunted by the idea of defining a miracle, but I like the direction you are agoing regarding miracles in daily life.

My thought–and my question– is about whether we will be more successful with software if we recognize just how difficult it is and how many factors need to come together to make it work. The sense of miracle to me suggests that there are factors outside of our control that determine success or failure. Will it make us more successful if we appreciate the difficulty? Or will it just leave us compacent?

My instinct tells me that if “resilience” is a factor of success, appreciating the positives is a posture that will help us succeed.

So in one sense, miracles are everywhere, we just have to see software and the projects that drive them as such. Is successful synonymous with miraculous? If so, is there a difference in thinking of successful projects as miraculous?