3 ms·

I've observed and participated in a reasonable number of projects, both IT and otherwise. In my experience there are two problems that seem to exit in every pr

I've observed and participated in a reasonable number of projects, both IT and otherwise. In my experience there are two problems that seem to exit in every project that either failed or had to go on to life support: 1. The deliverables were not clearly defined and maintained. How can you deliver something if you don't know what it is? In many cases there is either not a clearly defined and understood deliverable. This leads to every project officer having a different idea as to what they had to deliver leading to disagreements and conflicts and allowing external manipulation and scope creep. 2. People who have a vested interest in the successful outcome of the project are not directly involved in the delivery of that project. How many times have you seen a project team employed to deliver "the new product", only to then have it handed over to the operational support team, who then have to try to work out what this monster is that they have been given and how they are every going to get it to work in the way it was originally specified. You see this a lot when you have a system replacement being designed and developed by an external team, then handed to the people who supported the old system. Who best knows the task the old system was designed to complete, who knows the edge cases and peculiarities that system had to handle, and in most cases, who came up with the work arounds that kept the old system working. If you are going to replace a system, and you are going to maintain your current team to support the new system, then get them working on the development of the new system. Not only will they be invaluable in identifying edge cases that the project architects may not be aware of, but as they are going to be the ones who will have to live with the new system, they will do their bests to make bloody sure that it's going to do what is's supposed to. Oh and make sure they are in a position to call out things that just won't work.

magicalhippo 6y ago
> People who have a vested interest in the successful outcome of the project are not directly involved in the delivery of that project. I see that a lot at work. I can easily spot the birth of a troubled project just by looking if the people who'll be using it is represented or not. In fact just last week I saved our customer a lot of money and pain by pushing on a team leader to get involved in their project to switch ERP solution. I was working on the integration between the new ERP and our program and noticed the users of our program were not involved at all, so leaned on the team lead to rustle her feathers. This team is small but performs an essential job for the company, if they can't do their job things grind to a halt. After the team leader got involved she quickly discovered another department had gotten a change in which would be a complete showstopper for her team. Undoing this change after it had rolled out would have been non-trivial. Fortunately it was still early days in the project. This is the most recent example, but yeah I see it all the time. The ones where the right people aren't involved invariably end up bad in one way or another.

magicalhippo 6y ago

> People who have a vested interest in the successful outcome of the project are not directly involved in the delivery of that project. I see that a lot at work. I can easily spot the birth of a troubled project just by looking if the people who'll be using it is represented or not. In fact just last week I saved our customer a lot of money and pain by pushing on a team leader to get involved in their project to switch ERP solution. I was working on the integration between the new ERP and our program and noticed the users of our program were not involved at all, so leaned on the team lead to rustle her feathers. This team is small but performs an essential job for the company, if they can't do their job things grind to a halt. After the team leader got involved she quickly discovered another department had gotten a change in which would be a complete showstopper for her team. Undoing this change after it had rolled out would have been non-trivial. Fortunately it was still early days in the project. This is the most recent example, but yeah I see it all the time. The ones where the right people aren't involved invariably end up bad in one way or another.