Client types in IT development projects
Software development is a team effort. Today's systems are technologically complex, but they are expected to provide a good user experience and to support rapid development.
Methodologies for creating software have also evolved – instead of the previous large-scale development at a slow pace, flexible and iterative methods have taken over almost everywhere, and they require the client and the developer to be in contact practically daily.
It is fascinating to work with clients who are interested in the new system. Such clients provide invaluable input on any functionality of the system and its priority. They have a knowledgeable say in the technological choices and they have enough time for the project. In such teams, where everyone is aiming for a shared goal, cooperation and trust develop, and the results usually speak for themselves.
Unfortunately, this is not always the case. We are aware that we ourselves are far from perfect; however, we summed up the courage to write up a light-hearted and humorous description of the types of client representatives, whose participation in a project makes it a much bigger challenge for everyone than necessary.
NB! The people described below are not real people, and any resemblance to actual people (e.g. having the same name) is coincidental.
Invisible Mark
Mark is a member of the workgroup appointed by the client or, in more severe cases, a project manager who is seldom present at the meetings. He does not respond to e-mails within a reasonable time nor call back, which means that any input, feedback and decisions are delayed.
If there are enough of other client representatives on the project, then the situation is not very bad, and the necessary input can be obtained from other members of the workgroup. If not, however, things can get bad: the project team’s motivation suffers, the project lasts longer than planned or, in the worst-case scenario, it may fail altogether.
Benji-Mary
Mary is a key customer representative. She has a significant influence on the project and a desire to contribute to it, but for whatever reason, she does not have enough energy or time to deal with it regularly. She does not trust her team, but strongly believes that her opinions are always the correct ones and that decisions that have already been made can always be changed.
Mary participates in the project chaotically – sometimes she is there, other times she will not be seen for a while. She is not very up to date on the current progress of the project, but she likes to make decisions and set new requirements and will then disappear again. As a result, there is constant going back and forth in the project, tensions and stress are high, and it is hard to keep a positive attitude on the team.
Andres & Pearu
The more flexible the development model of a project, the more the whole team is in daily contact with the substantive client. Unlike Mark and Mary, Andres and Pearu are always present, but unfortunately, they are always fighting.
Meetings are spent arguing, and agreements are challenging to reach, which in turn has a detrimental effect on the motivation of the whole team. When this is combined with a weak project manager, the result is chaos. The development partner cannot take on the role of mediator and/or decision-maker!
The developer can listen to the arguments and wishes of both parties and offer solutions based on that, but a successful project requires that the people in the role of the substantive client want to work together in the name of the same goal.
Design Fan Jan
Jan is really only interested in one aspect of the project - appearance or visual design, not so much what the new system should do at all.
Working with Jan is exciting, like it is with anyone who is a huge fan of their field, but it is important to remember that design is not a system. In other words, there is the risk that some of the vital sections or functionalities of the whole project may not get analysed and realised.
Technology Guru Peter
He knows exactly how much time anything in development takes, he knows the hottest technological solutions and often imposes his favourite technologies on the team.
For example, Peter may have seen a demo of a solution or framework that is still in beta at a conference, but he has no actual experience with it. In reality, these kinds of solutions usually do not work as initially intended, and then Peter will start pointing the finger at the development partner and claiming that the solution cannot be implemented sensibly. All in all, it creates so much headache and unnecessary extra work for all parties.
In Conclusion
A sound software system is a joint creation between the client and the developer. Systems are created by people and any weaknesses will always leave their mark on the result, whether they originate from the client’s side or the developer’s side or whether they stem from a lack of sufficient skills, one-sidedness, or a lack of time or interest. We described the challenges that come from the client’s side above, but there will definitely be a part two to this post where we will talk about our mistakes as well!
