Login
User Name
Password
The following is a very roughly description on how software development could happen. It's a bit like a caricature: typical characterists are outlined more clearly than they are in "nature", so they can be recognised easily. Of course, most people work much more thoroughly at software projects like described here. But then these project become really expensive, and this is why they are quite often not done at all. So let's pretend things would be easy to get and quickly be done, because only then it would have been the chance to be accepted by the project manager we talked about in the last chapter.
The task driven from the previous chapter is: provide an extension of the planning software to present the completion statements of the production manager so the project manager get's an overview that can be shown to the customer. The spreadsheet prepared by the project manager shows how it should look like.
First step: analyse what the result should look like, and how it is related to the data already present in the planning software. Of course, we ask the designer of the planning software to take this task.
The condition: it's a small thing, nobody should invest much time, the project manager is currently not available because heavily involved in the project, but we have the spreadsheed, so it's clear how it should look like. And the production manager can help, because he is sitting close by, so the software designer can catch him on the floor.
The designer sees with his eyes: a list of features = the feature list of production. Task completion dates as completion milestones. Priorities as defined for production. These condition for coloring:
Top priority tasks:
Medium priority tasks:
Low priority tasks:
Should be easy. Just let's check the software structure:
some UML...
Yes, this little spreadsheet is dealing with complex information.
Still, it was easy. Adding a new report sheet, implementing the conditions, struggling a bit with the fact that production has four priorites 1,2,3,4 but the project manager talks about three priorities, so 1 and 2 are mapped to top, 3 is mapped to medium, and 4 is mapped to low. We talked with the production manager, and priorities 1 and 2 are usually seen as top priorities, or the production is considered to be failed. Mapping priority 2 to medium would be less conservative, but we want to be on the safe side, and better nothing important slips through. Initially, the feature list comming from production was much longer, so a checkbox for each feature was added to mark those relevant to the project manager. And the project manager needs this chart for presentations: so a snapshot function was added, creating an image file to be included in the presentation tool. The software development department looks ahead!
Well, the result looks different from the input - much more red and yellow. But two weeks passed by, and maybe the project is already in a less good state. And the production manager confirmed that the data in the new chart is correct. Certainly an important information for the project manager. Good we did this tool, now he or she is able to get most actual information any time.
Proudly presented to the project manager, the reaction was as quick as sobering: I did not ask for it, and I can not use it, as it does not match what I need. I'll stick with my spreadsheet.
What happend? Everything looked so clear and easy. This is what could have happend, and why even such an obviously easy thing quickly becomes a serious software development project:
What can we learn from this example:
What do we want to achieve:
Provide a software system that is as attractive to the project manager that he or she jumps over and really uses it. Let's see how it could look like in the next chapter, and how it can be used as a defining criteria for Holistic Programming.
Contact • Data Privacy