Reference no: EM131845114
Case Study: Project Management at Dotcom.com
Dotcom.com, a software engineering and systems development consulting firm, sells a wide assortment of Internet and computer-based solutions for resource planning, administrative, and accounting networks to organizations in health care delivery, financial services, and hotel management. Typically, a service provider approaches Dotcom.com with a list of problems it has and some targets for organizational improvement. Because most of Dotcom's clients are not themselves computer savvy, they tend to rely heavily on Dotcom to correctly diagnose their difficulties, propose solutions to correct these problems, and implement the new technologies. The industry in which Dotcom operates is extremely competitive, forcing successful organizations to make low bids to win consulting contracts. In this environment, project management is vital for Dotcom's success because poorly managed projects quickly "eat up" the profit margin for any job. Unfortunately, Dotcom's senior management team has noticed a recent upsurge in project operating costs and a related drop-off in profitability.
In particular, Dotcom's executives are concerned because the last seven consulting contracts have resulted in almost no profit margin because the software systems were delivered late and required several rounds of rework to fix bugs or correct significant shortcomings in the software. The firm decided to hold a weekend off-site retreat with the project managers responsible for these most recently completed projects in order to learn why project management was being done so poorly. To a person, the project managers fixed the blame for their problems on the clients. A typical response was made by Susan Kiley, a project manager with more than five years' experience, who stated, "We are put in a very tough position here. Most of the customers don't know what they really want so we have to spend hours working with them to get a reasonable Statement of Work that we can develop the project scope around. This takes time. In fact, the more time I spend with the customer up front, the less I have to get my team to actually develop the system for them. It's a Catch-22-If I want to get things right, I have to pry information out of them.
The better I do getting a sense of their problems, the less time I have to develop and run the project!" Jim Crenshaw, another project manager, spoke up. "It doesn't stop there, unfortunately. My biggest problems are always on the back end of the project. We work like dogs to get a system up that corresponds to the client's demands, only to have them look it over, push a few buttons, and start telling us that this was not anything like what they had in mind! How am I supposed to develop a system to solve their problems when they don't know what their problems are? Better yet, what do we do when they ‘think' they know what they want and then when we create it, they turn around and reject our solutions out of hand?" After two hours of hearing similar messages from the other project managers, it became clear to the senior management team that the project management problems were not isolated but were becoming embedded in the firm's operations. Clearly, something had to be done about their processes.
Questions: - How do you balance the need to involve clients with the equally important need to freeze project scope in order to complete the project in a timely fashion?
- Why are configuration management and project change control so difficult to perform in the midst of a complex software development project such as those undertaken by Dotcom.com?