The Subway Meeting
I should have realized the degree of the organization's angst when she wanted to meet at a Subway Sandwich shop. No offense to Subway, but it is not the typical venue area for contract negotiation. When I arrived, my friend, we will call her Sara, had dozens of document and numerous three-ring binders strewn across the table. "Thanks for meeting me here. Had I brought you into the office all hell would have broken loose." The periodic panhandler was the only distraction to our three hours of poring over program documentation, status reports, team member profiles, and the core dump on the company politics. Eventually, we concluded that the project could be rescued and that there were plenty of other benefits in a recovery—since this was only one project in a long string of failures, identifying and correcting the underlying problems would be the greatest value.
The First Meeting
A few days later, time and materials contract in hand, I was meeting with corporate directors over breakfast at the Hilton. They explained their concerns about the project. It was obvious that they were frustrated with the situation and were unable to get consistent answers from anyone on the team. By the end of the meeting, they outlined a series of areas they wanted investigated. The primary one was whether the project was following their proprietary project methodology. To help, they had already set up a number of meetings with key stakeholders so I could sift through the mess.
The first meeting with project team members was a quick education in the extent of the problems. This initial meeting was supposed to be a one-on-one meeting with the project manager. However, she could not make the scheduled time, so she suggested I attend her weekly leads meeting. That meeting, too, was difficult to arrange and had been set up as a 'working lunch' in a conference room.
Of the three leads, only two attended; both were obviously annoyed as they munched on their lunch between verbal jabs. They tried in vain to get the project manager to make the decision or delegate the authority so they could put bounds around scope to close requirements gathering. The project manager kept asking her lieutenants to complete the requirements; however, she would not give them the authority to limit scope. The interplay was viciously circular making the meeting frustratingly ineffective. Everyone left exasperated.
 |
|
Ask for more info above, or if you are convinced, just add it to your cart.. |
Look at the
|
The Endemic Problem
The interviews continued including samples from the C-Suite to the testers. The further the person was from the C-Suite, the more bizarre their comprehension of the project's goal. To my amazement, though, the element of the project that had the least consensus throughout the organization was who would be the system's primary user. The team was trying to build a tool and was misaligned on who would eventually use the product.
The project's archive held the answer. They clearly showed who would be the end user; however, the project charter never defined them. I asked the director of the PMO if the approved chapter was complete. She replied, "It has all the sections we require." When pressed further she relented that the people in the PMO did lacked the business knowledge to know if the content was appropriate. No level of process, proprietary or open, will overcome lack of knowledge.
Finding the Root Cause
The story could continue. Senior management insisted the project was the problem; however, upon identifying the end user, the project ran fine and achieved its goals. People were following the internally designed processes, but no one was validating that the content of the deliverables was appropriate. Poor data fed process steps and deliverables had no value. Garbage in, garbage out.
The culture placed process above content. The approach to running projects, managing people, guiding communications, and making decisions was faulty. The only solution was to have someone outside the organization—objective and unbiased—analyze the organization. Internal auditors are at a severe disadvantage. They are part of the culture, politics, and finger pointing.
External Audits
Although routinely done in accounting, Information Technology (IT) groups rarely request external audits. This may be due to the maturity of accounting (many credit its genesis to Luca Pacioli in the fifteenth century with references to auditing even earlier) and the relatively young IT discipline (less than sixty years). Speculation on the reasons may be fun, but are irrelevant. The solution is to create an open culture that embraces the audit. Not just of projects, but of all IT operations. Recently I was involved with an IT audit. A client brought us in to help with their compliance. As with project audits that I have conducted, the external auditor sets the stage for a smoother running operation and a culture acceptant of criticism as a constructive tool.
.gif){kind=spacer}
