My old­est brother, a man­ager in the soft­ware indus­try, once told me the fol­low­ing story. He was work­ing for a client and the local man­ager was strug­gling in his job and real­iz­ing it. So dur­ing a con­ver­sa­tion he had with my brother, in which he dis­cussed his predica­ment my brother told him the following.

“Look, I under­stand where you’re com­ing from, but you have to under­stand this: for me to be able to do my job as a project employee you have to give me a hall stand. That way I’ll be able to hang my coat so to speak. If I don’t have that I don’t know where or when to start.”

Steer­ing the Soft­ware Project With Your Design

To steer a soft­ware project with a soft­ware design you have to know where and when your soft­ware design can and/or will be used dur­ing the soft­ware project. That’s pos­si­ble because man­ag­ing a soft­ware project can be ratio­nal process. The only thing not being ratio­nal is clients demand­ing a project plan and time esti­ma­tion while they them­selves don’t even have put on paper what it is they want? How do you deal ratio­nally with irra­tional­ity? Give in and come up with a plan­ning based on arbi­trari­ness? I hope not.

“Unre­al­is­tic plan­ning is the same thing as shoot­ing your­self in the foot just before run­ning a marathon. Of course, it can be done, but it’ll at least be a bloody and painful affair.”

The Soft­ware Project Hall Stand

Like my brother said, you need a hall stand. It’s the only thing that will focus project employ­ees atten­tion less on each other and more on the sup­pos­edly shared end result. I have dis­cussed the metaphor of “ecosys­tem” and intro­duced the term “phase” because I don’t blindly believe in a thing like project plan. The plan­ning of a soft­ware project is a phase in itself. It’s not an end although some peo­ple make it so, it’s a means to an end. But more so the dynamic view of an ecosys­tem, some­thing vibrant, some­thing dynamic, some­thing alive is what cap­tures the essence of soft­ware engi­neer­ing so much more.

“Mak­ing a solid soft­ware project plan isn’t even half the work.”

“It isn’t?” I hear you say. No, the real work starts after we’ve made a plan or maybe even before. Because assigned stake­hold­ers have to show that often mis­used word “com­mit­ment” so that all of the fol­low­ing described project phases will be able to bear fruit in our soft­ware project ecosystem.

“50% of all the work I profit from the most isn’t the work I enjoy the most.”

It has to be done nonethe­less. Mak­ing a plan is easy. After that we really have to roll up our sleeves and get busy.

Under­stand­ing Soft­ware Project Phases

Because soft­ware design­ing is so intri­cately involved in almost every phase we have to know and under­stand them. The more so as this site squarely places soft­ware design­ing on the fore­front of qual­ity soft­ware engi­neer­ing. Remem­ber I said soft­ware design­ing is about empa­thy and empa­thy is about under­stand­ing? Even though we don’t have to be inti­mately involved in every soft­ware project phase we have to under­stand what each phase is about, we have to feel what project par­tic­i­pants feel in order to make a bet­ter “fit” between our soft­ware design and it’s var­i­ous stake­hold­ers. I once lived with a friend who has a pho­bia for fish. I never made meals with fish in them, or maybe once just to watch him throw up after he ate it and I told him what was in it.

Metaphor­i­cally speak­ing, some peo­ple have design pho­bia, don’t make them throw up.

Don’t make designs peo­ple don’t want or can’t use dur­ing their work. Do what works. We’ll be far more able to do this when we under­stand project phases and under­stand how we can help our col­leagues in their work with our designs. And its project phases which are the hall stand nec­es­sary to bring soft­ware projects to a suc­cess­ful conclusion.

Related posts:

1. Func­tional Spec­i­fi­ca­tions: the Soft­ware Project Ecosystem