Dotcom.com Management and Communication Problem Resolution Discuss how you would begin redesigning dotcom.com's project management processes to minimize the problems it is experiencing with poor scope management.

To minimize Dotcom.com's problems in connection with poor scope management, I would begin redesigning the project management process by first explaining a few fundamental issues to my team that are much broader than just project management. I would explain to my team that the very nature of our relationship with our clients is that we are technologically savvy and experienced and they are usually clueless in comparison. Therefore, we can never rely on a reactive approach in which we assume that clients know what they want or that what they may think they want is actually what they need. This fundamental conceptual understanding of who should be taking the lead in the relationship with clients is essential and much more important than the finer issues of project management. In principle, as long as anybody on our project development fails to take the lead in that regard, our firm will always lose money on any projects where the profit margin is tight in the first place.

Because we are experienced about how software works and about what is realistic and unrealistic when it comes to translating clients' desires about end-user functionality into system capabilities and management, we can not afford to take a passive role in the process of communicating with our clients about what they need and what options are viable to achieve their goals, as well as what possible complications and limitations must be considered in connection with their needs. Our clients have no idea what kinds of problems or limitations could materialize after we provide them with exactly what they think they want us to provide. We, on the other hand, are supposed to be the experts and part of our job is, precisely, to consider, in advance and before we waste time and money on actually implementing clients' desires into systems.

If we simply take notes when clients explain what they want to be able to do and then provide them with systems based on their initial requests, we are guaranteed to run into continual problems when clients discover for the first time only after implementation during live testing that there were things they did not realize they should have considered, questions they did not ask that needed to be asked, and possible...

It is our job to point out those considerations at the earliest possible (i.e. The talking) stage, to consider the possible implications and limitations of every decision made in advance, and to point out all of the foreseeable consequences in advance that our clients will not recognize until after the fact but that we should be able to identify and anticipate in advance and before we invest any time, energy, and money into blindly following what our clients tell us they think they want from the systems that we design for them.
Going forward, to eliminate this problem, I would require each project manager to assign an individual to the task of client liaison and that person's main responsibility in that capacity would be to sit down with the client at the outset and go through every element of the requirements that the client requests one by one. Before initiating any substantive work on the project design, the client liaison should conduct a preliminary feasibility analysis, either independently or in conjunction with someone from the technical team to discuss what possible considerations the client may be oblivious to, what conceivable limitations or conflicts the client could not possibly anticipate, and (most importantly) exactly what questions to take back to the client to resolve the potential issues that we, as experts, must always anticipate even though our clients, as non-experts, can not be reasonably expected to anticipate. Finally, I would establish an organizational culture based on the idea that nothing is ever the clients' "fault" unless the client actually changes his mind about the end-result he wants. If something the client asks that our system be able to do leaves out another consideration that should have been addressed, that is never the clients' fault; it is always the fault of our project management personnel for failing to bring the potential problem to the clients' attention in the initial stages of project planning before any time and money is wasted on actually developing a system that does not address the questions that we should have known to ask ahead of time.

Why do you think configuration management and project change control are difficult to perform in the middle of a complex software development project, such as those implemented at dotcom.com? Share any experiences you have with project change requests.

In m…