When things go wrong in connection with major IT projects from the very beginning, it has a lot to do with psychology, attitudes and (lack of) self-knowledge. We all can be a little too ambitious, a little too optimistic, but we can also be a bit too overcontrolling, impatient, sometimes maybe even selfish.
This article is not specifically addressed to development teams even though they can probably relate some of it to their work, but it is more for project leaders.
Let us look more at a general approach and attitude. I will not specifically target the PM domains (e.g. Initiation, Planning, Execution, Monitoring & Control, Closure). On the other hand this article is also not about the technology stack, processes or the right frameworks (should it be Scrum, Kanban, Agile at all or more a Hybrid). And I hope you will see the irony sometimes.
Here are the safest approaches to running a promising project well and thoroughly over the edge:
One of the basic rules in sabotaging large collaborative projects from the very beginning is: trust your assumptions. Do not clarify and just assume you’ve got it right.
Imagine the all too familiar scene: You are discussing with the customer the project requirements, the scope, expectations, timeline and as soon as it starts everything is so clear for you. You understand the customer’s need perfectly, it all makes sense. You feel like this is going to be a walk in the park. Why do you even need a developer or an architect or a business analyst for clarifications? It’s a waste of time.
You assume and are sure that is correct. Right?
Many of you can probably remember a well-known meme about the expectations vs. reality in software development. Well, assumption is not the only ingredient here, but it is a good illustration of what it can lead to. And the worst thing is that the customer will also assume you’ve got it right.
Do not trust your team Trust is an extremely sensitive matter. It needs to be earned and proven, maintained and checked all the time. Even if someone has done what was promised, it does not mean at all it will happen next time. Probably it was done for personal benefits or out of a fear or it was just pure luck. And we do not want to leave the success of the project to the luck, do we?
So, you need to control the team, since you are not sure they understand the tasks. You are not sure they do the right estimates. You are not even sure what they do all those days, discussing, planning, reviewing something. Oh gosh, is that the third coffee someone is making?
So why don’t you just go right to the point and question the efficiency of the time spent. Why don’t you monitor the utilization? And why not plain out tell them what to do, otherwise there won’t be any progress, right? Or not really…
I guess many of you would agree that people are hired for knowledge, experience, attitude, and ability to help reach the business goals. So why is it, we always have to tell them what and how to do and enforce our own perceptions?
This probably blends well with assumptions in the first point, but it is a much better technique. It will definitely improve your customer satisfaction and impression of the capabilities of the team. After all, the customer is always right, knows better what should be done, how and when. And obviously your mission is to satisfy all the customer needs, isn’t it?
So, the customer sets the delivery date to create a birthday present for CEO. Sounds great! The scope includes wishes from all departments, and all of that is super important. Sounds perfect! Major changes are introduced since someone was on vacation or changed his mind. Well, let us just add it to the scope! Daily status reporting is suggested. Sounds reasonable, even I do not fully trust the team!
Let us not forget that we live in a world of limitations, that can be dictated by numerous conditions. Although we try, we cannot please everyone and satisfy each and every request. One of the main points of project management is to find the most optimal way that brings the right value at the right time….
The best way to enforce hierarchy is to limit communication and collaboration, be protective and avoid transparency and visibility for everyone, since you are in control.
Transparency my ass - you give the tasks, and the team should just do it. The only visibility needed is the project task status - a check mark for the major milestones. When everyone only knows the status of their own project task, unnecessary discussions can be avoided - and new ideas will only delay the project anyway, right?
On top of that you can add an authority pressure, where employees become hesitant to bring up potential problems or simply don’t have the “guts” to question the decisions. How about this level of communication?
I reckon you have also seen many projects which failed due to poor communications between stakeholders, mainly between the management, customer, and the team. Poor communications create a bottleneck which causes the lack of information – and the team members must spend too much time and effort on exchanging information with other stakeholders and sharing project data. In fact, some statistics make poor communications between people within projects the “number two” reason for PM failures.
Do not explain why This is another level of mastering the power of limited information. Knowing the big picture by the teams is overrated and is just a waste of energy. Is it really that important for the team to understand how their pieces are contributing to the whole, to have a common goal that is visible and understood?
The project team is made up of people with the right specialized skills, so there is no need to talk things to death and over-communicate. The specialists just need to focus on their tasks, and make sure they are done on time. They all have their individual goals and work on isolated items according to the planned tasks. What else is needed? You will decide who, what and when needs to know, otherwise why are you there? Vision, goals, roadmaps, delivered business value – leave all these to the management, don’t overcomplicate things.
In my experience one way to almost guarantee project failure is to begin work without clear project objectives and goals. All team members need to know the goal and fully understand it and the business value in order to work in the same direction. After all, there’s no way to know whether you’ve succeeded when you aren’t completely sure what you’re trying to accomplish.
We have explored the recipe for project failure, but what does the failure mean? This is not only the upset customer, who is paying for the project and expects to get value. This is also relationships that gets undermined, something that can be built over a long period and go to vein within weeks.
Failure is also associated with learning. And while I fully agree with that statement, I believe we can try to create an atmosphere where learning is encouraged while successful projects reach new milestones.
I will try to explore a recipe for success in another article. I hope you will enjoy it in the same way.
At SoftwareOne, we combine strategy, technology, data science and design based on the needs of our customers, to create solutions or services that enhance their business models.
At SoftwareOne, we combine strategy, technology, data science and design based on the needs of our customers, to create solutions or services that enhance their business models.
