|
You can’t work in this field long without experiencing a project that falters. You can, however, examine and learn from failed projects — your own and your peers' — to try to avoid some of the same minefields. Here are five fundamental lessons learned from a troubled project whose daily mantra was “every project has an end!” Wedged between the PMBOK Guide and Quentin Fleming’s treatise on Earned Value Management, Watty Piper’s The Little Engine That Could occupies a place in my project management library. The childhood classic story — about a small engine that manages to pull a large train over a mountain after larger engines refuse — serves as an optimistic metaphor for making it through a challenged project. Unfortunately, there are also those doomed initiatives that would more aptly be tagged “The Little Project That Couldn’t.” A few years ago, I was an analyst assigned to implement a state-of-the-art employment recruiting website. The site would position the company as the premier employer of choice during the ongoing war for talent. Two different vendors were selected for the project based on positive experiences in the past with the company. One vendor would create the design and employer brand; the other would develop the candidate tracking and assessment tools. The company’s information technology organization was responsible for internal tracking tools and overall integration management. With nine months to complete the project, the entire team thought there was sufficient time to deliver all the requirements before the fall recruiting season. Referring back to your favorite organizational behavior textbook, you’ll recall team development typically follows a process of “forming, storming, ‘norming’ and performing.” The project had a successful team-forming phase with executive dinners. Unfortunately, a spiral of continual team storming through long nights over cold pizza followed, and this is where some valuable lessons from the Little Project That Couldn’t began to be learned. Lesson Learned #1: Define clear roles and responsibilities Defining the roles and responsibilities with the project sponsors, team members and stakeholders, and specifying deliverables will help establish alignment before a single dollar is spent. In my failed project, the director of Human Resources, the main project sponsor, directly managed the project team as well as set strategic direction. Project teams would start developing a section of the website only to scrap the work because the project sponsor deemed it appropriate to change direction. There was no clear project organization. Every vendor and employee reported directly to the project sponsor. Instead of following established procedures or communication channels, everyone went to the director with issues. Consequently, the HR director struggled in the multiple roles of executive project sponsor and program manager while fulfilling the regular HR responsibilities. Clear direction was impossible to determine unless the project team verbally heard from the project sponsor. We were two months behind schedule with six weeks remaining before the original launch date when over a late dinner of chicken burritos, the project sponsor announced, “From this point on, I will directly manage the project schedule.” I still cringe when I think back to the moment when we shelved our Mexican hot plates and started drafting a Gantt chart on the back of the restaurant’s placemats. Establishing clear roles and responsibilities upfront would’ve provided better guidance and avoided requiring the project sponsor to directly manage the project. Lesson Learned #2: Don’t swap your project manager midway One of the detrimental impacts to the project was the constant change of project managers responsible for overall delivery and integration management. Early in the project, my direct manager was the project manager. The project sponsor soon shifted the project management role to the vendor’s “project management” staff. The vendor’s project management capability was low, and the role soon shifted back to the sponsor’s internal IT staff. At this point, the project was far behind schedule, team credibility was low, and the relationships across the various vendors and team members were significantly strained. Dissension, distrust and frequent “cover-your-keister” behavior soon emerged. The project suffered from overall lack of direction and authority. It became increasingly difficult to formerly authorize a project manager to mobilize resources to perform the work when the project manager kept changing. It didn’t get any better when the project sponsor decided to assume the project management role. Lesson Learned #3: Manage by the project schedule This obviously requires the project manager to actually create a project schedule to track activities and progress. Don’t laugh. I’ve seen a few projects that simply manage a project with a handful of key deadlines. The project schedule is a living document. It isn’t meant to be drafted once and shelved on someone’s computer or file drawer. The schedule needs to be updated and reviewed each week. Schedule and cost variances need to be monitored and project managers need to take corrective action. On my project, only one vendor had a project schedule. The other vendors and team participants simply used daily issue management to get work done. All of them promised to deliver the work by the launch date. However, only the vendor who established a project schedule successfully delivered its work on time. I was a low-level business analyst on the project with little project management experience. However, since I had a copy of Microsoft Project on my desktop, I started developing a sample schedule. The director walked by and asked what the activities, dates and progress bars represented. This was the pivotal moment in the project when I was heralded as a genius. The project sponsor soon decreed the project would have an integrated plan and an ad hoc PMO was formed to track project progress. It was only a minute of fame and glory, but in a troubled project, I claim my victories when I can. Lesson Learned #4: Prioritize project scope When rescuing a troubled project, understanding the project scope’s prioritization is imperative to successful recovery. Despite all the demands to deliver the entire project scope, the project triangle of time, scope and resources still applies. If the scope is fixed, time and resources must adjust to the scope requirements. Unfortunately, on my failed project, the sponsor provided the detailed business requirements but refused to prioritize scope. The website brand, candidate assessment module, employee profiles, and campus recruiting modules were all high priority. Software development teams were busy writing code while professional photographers were holding photo shoots in the hallway. When the integrated project schedule revealed the project was two months behind, prioritization fell upon deaf ears. The end result was the project team entered into a heads down death march to complete the project. Instead of focusing on the key modules that would support the upcoming recruiting season, the teams were instructed to deliver the full scope. Despite the decree to deliver everything on time, the original project end date passed and the team was only able to deliver 60 percent of the project. The portion that was delivered suffered significant quality and performance problems and needed rework. If the project team had prioritized the scope, they could’ve focused on the critical deliverables required to support the recruiting function. Despite executive mandates, you can’t hold all three sides of the project triangle fixed. Lesson Learned #5: Establish a change control process Scope change control is a key sub-process in project management. Scope planning, definition and verification need to be applied while scope change control manages change. The recruiting project didn’t have any endorsed change control process. Three months before the launch of the website, the project sponsor asked the project team to investigate additional vendors to assist with managing candidate data and automating the hiring process with the company’s HR and payroll systems. No impact assessment was conducted. No prioritization was provided across the portfolio of work. The project team drafted requests for proposals, attended vendor conferences, conducted site visits and hosted reference calls. The project team reached its tolerance threshold when they were told to have the website play MP3 files while candidates searched for jobs on the site. The lack of change control directly affected the team’s focus. The lack of a defined project organization and consistent project management resources, poor prioritization, and missing change control processes affect projects of all sizes. These problems exist in all companies ranging from the start-up consulting firm to a Fortune 500 company. It may surprise you to learn this project failed in an organization with established project management capability and maturity. It can happen to any organization. This article was written by Andy Makar and originally published at Project@Work
|
