The Chicago Software Association held a seminar today on Why Projects Fail and What You Can Do About It with three speakers who focused on different aspects of the question. All three agreed on the main theme: Communication, early and often, is critical to successful projects. The speakers talked about the human aspects of project management, but no one talked about Theory of Constraints or Critical Chain Project Management directly.
David Press, Principal Consultant at Greenbrier & Russel, emphasized the critical need for IT and business to be open and able to communicate with one another at the right levels. Gezinus Hidding, Assoc. Professor of Information Systems at Loyola University, spoke from the perspective of what students of his project management courses need to know. And Matt Furton, Partner at Gordon & Glickson, LLC, spoke about the legal issues associated with project failure, focusing on how to avoid problems. Not surprisingly, the key is communication.
David Press did a great job of summarizing the problem of project failure and reminded the audience that most project failure has nothing to do with the technology and everything to do with people and communication.
Every time Matt Fulton sees a new client, the issue boils down to a communications failure. His remedy is to convince people to build the communication relationship early so that all parties involved come away with a clear understanding of what project success means and who is responsible. He suggests that people don't like to do this because working out these details is hard, and they would rather jump into the "fun" work of the project itself. I can concur on this point - we had to build business processes around clearly identifying expected outcomes and get agreement from all the stakeholders. In a few instances, we had to reject project plans because not everyone agreed to the demands of the project as it was presented.
To emphasize the idea of communications and building common understanding before engaging a project, Gezinus Hidding threw this question to the audience: If you are asked to build a database to help increase sales, what is the project?
Press provided another communication and language example in graphical representations of an IT project and a business project. Besides having a left-to-right timeline, the look of the two graphics was totally different, reflecting significantly different perspectives on talking and thinking about projects.
Press described failure as a moving target, depending on where you sit within an organization. A software developer fails if their code requires constant babysitting and troubleshooting. A project manager fails if the project is cancelled due to problems within the project tasks, but doesn't she also fail if the project is over-budget, under-scope, or over-time? Program manager failures might be associated with constant under-staffing or budgeting problems. And business leaders see failure when a project doesn't achieve expected payback.
In this framework, it is clear that an organization needs to look across all these aspects to help manage at the right level. Press suggested that the best way to do this is develop an IT Governance organization as a part of the executive leadership of the company to ensure all IT work has a firm basis in the strategy of the organization. He predicts that IT Governance will become an important concept over the next several years. IT Governance is much more than the Program Office or Project Management Office, which traditionally focus on resourcing and managing across multiple projects. IT Governance relies on these functions but also adds more connection to the business strategy. Press also suggested that, with the rise of importance of conversation between business and IT, the role of a liaison between the organizations would grow. As with any liaison, this person will be able to communicate and translate the languages and concerns within both organizations.
The discussion of governance reminded me of the presentation by Jonathan Worstell of Shell at the AIChE meeting in November. He talked about concurrent engineering as a team that incorporates all stakeholders and ensures the projects are kept on track with the direction of the organization. Project governance is clearly something that applies to more than just IT projects. A well-run business needs to be relatively confident that its people are working towards a common goal, and this was Press' view of how IT governance should support the company. (Governance also refers to monitoring and control, such as with the current emphasis on financial accountability.)
Hidding made the interesting observation that, while most people think of project management as task management (a la Microsoft Project), he is not convinced that tasks are the right way to manage projects. He would rather see PM focus more on value added. I suspect there is a good way to combine task-based control with a look at value-add via the IT Governance or Program Management organizations.
Furton talked about the fact that projects are run in highly dynamic organizations. Even with clear specifications, there are changes happening in the environment that impinge upon the project all the time. The project itself morphs while it is completed. Technologies used within the project grow and change, as do technologies outside the project. People move in an out of the project. The client continues to run its business, and its priorities may change vis-a-vis the project.
We had a quick discussion about relative failure rates in information technology compared to construction. While we don't see buildings falling apart at the rates claimed for IT project failure, some people argued that if scope, budget and time are figured into the equation, that there are many construction projects (most?) that fail in one regard or another.