|
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 avoid some of the same minefields. Here are the final five important lessons learned from a troubled project that held one team meeting in a hospital emergency room. Still, 10 important lessons learned emerged from “The Little Project That Couldn’t.” Here are #6 through #10. Lesson Learned #6: Report objectively and ask for help earlier A root cause for failing to rescue the troubled project was the delay in communicating problems early on in the project. The project management team painted an overly optimistic view of the project status to senior management. When individual team members finally reached out to other executives for assistance, it was simply too late for the executives assist the project. The executive team responded with a senior project manager experienced in rescuing troubled projects although too much time had elapsed to make effective changes before the launch date. If the team had escalated earlier, the right project management resources would’ve been applied earlier. The much needed project management processes would’ve been applied to assist the troubled project. Instead of communicating earlier, people thought they could save the project themselves. The key lesson learned is to communicate truthfully and escalate earlier rather than trying to be hero. In the movies, the tragic hero dies on the battlefield, while the foot soldier holding the banner survives to call in the cavalry. Teams deliver projects, not heroes. Lesson Learned #7: Plan for quality management Quality planning, assurance and control are key processes within project quality management. In order to produce a quality product, sufficient time needs to be allocated in the project to ensure the project requirements were sufficiently met. Quality isn’t a byproduct of effective design and construction. Quality needs to be planned to ensure the design and construction of work products effectively meet the project requirements. In the failed project, quality management was an ad hoc afterthought rather than a proactive process throughout the project life cycle. The project team understood the need to test the website and ensure all the modules worked. However, when the project fell behind schedule, the software testing cycle was shortened from three weeks to three days. The project team launched the recruiting website in time for the recruiting season although the website crashed three days later. Expecting your target customers to test a product or service when it hasn’t passed your company’s internal quality processes is an effective way to lose customers. Lesson Learned #8: Recognize conflicting vendor interests When engaging multiple vendors on a project, it is important to be aware of the vendor relationship and expectations of the client and each participating vendor. This is especially important when the vendors have competing products or services collaborating on the optimum solution for the client. Vendors are constantly selling products and services. If there is a perceived business need, it is their role to try to fill it and to position themselves as the sole solution provider. When vendors with competing interests engage on a project, it can cause havoc unless it is appropriately managed. On the failed project, there were noticeable differences of opinion and an overall lack of knowledge sharing for fear of losing a competitive advantage. Both vendors had resume tracking systems to help HR organizations streamline resume management. One vendor perceived the other as a significant threat and a series of non-compete and non-disclosure requests were made. The end result was additional delays in implementing a solution that incorporated the best of both vendors’ products. I also learned a good nonverbal lesson learned. When working with multiple vendors, it is a good idea to leave any specific vendor marketing “Stuff We All Get” (SWAG) behind. Apparently, when I walked in with a pen and notebook imprinted with a vendor’s logo, it appeared I was favoring a specific vendor. I just thought I had a cool pen. Lesson Learned #9: Use a standing issues meeting instead of a sitting one If you have a need to meet daily to review project issues, apply a standing policy instead of a sitting one. Throughout the troubled project, we conducted a daily one-hour issue review at 8 a.m. By 9 a.m., we only made it through a third of the issues after rehashing the previous day’s actions and results. The 8 a.m. meeting was soon pushed back to 7 a.m. and then 6 a.m to allow more time to address all the issues. In hindsight, we didn’t prioritize the issues appropriately and wasted time discussing both minor issues and major issues. The minor issues tended to get resolved without requiring project sponsor attention while the major issues required sponsor involvement. If your project requires a daily issues review meeting, adopt a policy to stand throughout the meeting and only address the key issues that require immediate attention. Unless team members were former Honor Guard members at the Tomb of the Unknown Soldier, team members generally don’t want to stand much longer than needed. A standing issues meeting focuses on the key issues needing immediate attention and limits tangents conversations. It is especially helpful since key team members with limited time can drop in, respond to immediate issues, and can proceed with doing work rather than talking about work. Lesson Learned #10: Happy people = happy project I’m amazed by the managers who think that yelling at their employees or publicly criticizing them will result in motivated improvement or improved project delivery. Perhaps it stems from a manufacturing mentality where plant floor workers were “motivated” by their management with empty threats and criticism. I recognize this is a stereotype, but it illustrates the importance of valuing and respecting your project team. It shouldn’t be a surprise that happy people have a direct impact on a successful project. Maslow’s hierarchy is alive in the corporate workplace and if an employee’s esteem needs are not met, the project is at risk for dissention and failure. The project teams’ safety and physiological needs may be met, however, the team will not be motivated to creatively solve problems or accomplish tasks unless management meets its collective need for esteem. In my failed project, a manager openly criticized the project sponsor’s decision in front of the project sponsor and the entire project team. Given the power distance and hierarchal structure of the organization, you’ll need to speculate about the sponsor’s response, as it isn’t fit for print. Sadly, this was a noticeable rift that impacted the overall morale of the project. Projects don’t have emotions, but people do. Projects are accomplished through people. If you don’t have a motivated staff willing to overcome project difficulties, you don’t have much of a project. Despite all the stressful experiences and general project failure, the recruiting project remains one of my favorite project experiences due to the numerous lessons learned. It may have been considered the project from Hell; however, it opened up a new direction in my career. Working on the project inspired me to change my career direction from a business analyst to a project manager. I wanted to learn the processes, tools and techniques required to turn “Troubled Projects That Couldn't” into “Successful Projects That Could.” I hope these past 10 lessons learned from a failed project have helped you say “I Think I Can. I Think I Can.”
|
