I often see projects make mistakes that cause delays and budget overruns. Although the problem is in plain sight and the effects are clearly felt, not many people seem to see the problem. I call this issue by the analogy I use for it: a sweater.

How a sweater can keep your IT project on track

Your mother’s sweater

Just imagine the following situation:

On her birthday, Anne gets a sweater from her mother as a present. The sweater was custom made by Maria, an acquaintance of her mother. Unfortunately, however, Anne thinks the design of the sweater is hideous. Not to hurt your mother’s feelings she smiles and accepts the gift. Afterwards, she stuffs the sweater in a drawer never to be worn again.

This story has the holy trinity of any project: The one who will use the software (Anne), the one who writes/configures the software1 (Maria) and the one who pays for the software (the mother). In practice, the one who pays is usually the management.

Managers often assume that if a chosen solution is not the right one, people will speak up

In this example the sweater is never worn again, i.e. the project is scrapped. In practice that is rarely the case. Often, the software is eventually put into production, but not without costly workarounds or lengthy rework. Sometimes the issues are so big that a new project with a new software package, from a new manufacturer, is started. This can be the start of a cycle of software packages coming and going, every package never living up to its expectations.

Justin Bieber

How can we avoid this situation? Consider the following:

For Anne’s birthday, her mother gives her a home-made voucher. The voucher instructs her to create a design and then have that design made into a sweater by Maria. Anne decides to have Maria make her a Justin Bieber sweater. She can wear it when she's sleeping on the steps of the concert hall getting tickets for the next concert. The sweater is now very much used and very admired by all of Anne’s girlfriends.

Software that is right for the job is the one that will be used. And who has the most intimate knowledge of the issue to be solved: the users.

Why didn’t you say so?

Managers often assume that if a chosen solution is not the right one, people will speak up. In our little story, Anne did not tell her mother the sweater is rubbish because she is a figure of authority. In business there is a second incentive: you don’t bite the hand that feeds you. Even if people speak out, people try to say it as politically correct as possible, removing all the urgency from the signal.

In conclusion

Is your project in danger of the sweater-effect? Look out for the following red flags:

  • There isn’t a shared project vision or goal. For instance, when talking to project members and project management near the coffee machine, are you getting wildly differing accounts?
  • Are there hardly any users, i.e. people who are going to use the end product, involved in the project? Is the product owner the only user that is directly involved in the project? Are the users, preferably ones not participating in the project, attending the sprint demos? Are there users involved in the user acceptance test?
  • Is the documentation, instead of the users, the last word in discussions about functionality to be built? Contrary to popular belief, not everything can be built according to the design. Therefore the developer and tester must understand the intent of the design2; the intent which has not been recorded in the documentation.

If you see any of these red flags, try to convince the product owner and/or the project management to better involve the business. That way we can create beautiful sweaters that are actually going to be used.

 

1 - When buying a software product it always seems like you can use it without any modification. In practice, however, alterations are all but required since every company is unique

2 - For the first design, you think only about functionality. When implementing the design you have to contest with all kinds of technical restrictions. In any project, therefore, there will be some back-and-forth regarding designs.

About François

FrancoisI am a BPM developer and a Pega certified senior system architect with nearly 10 years’ experience in the BPM field. As software developer and process designer, I have worked with several different BPMS packages. I like to think beyond the constraints of my work and try to see the bigger picture. If you want to know more look me up on LinkedIn.