When a project’s late, over-budget or has simply collapsed, people usually start looking for someone to blame. That’s a natural tendency, even though it’s rare for a project’s troubles to be the result of any one person’s actions. The causes are often systemic and many: a lack of communication on the team, a stakeholder who wasn’t kept in the loop, a need to juggle competing priorities that didn’t succeed, or simply unrealistic expectations at the outset. Poor management may have been at play, or a lack of quality control. Every project’s different. Whatever the reasons, no one wants to be in management’s sights when they try to identify what went wrong. Fortunately, if you approach the situation calmly and honestly you should be able to weather the storm—and maybe even turn it into a positive. Click here to find a software engineering job.
Take Time to Reflect
If you feel the weight of the failure is being placed on you, first consider the charges. “Ask yourself whether the criticism is deserved,” advises Jordan Goldmeier, CEO of Dayton, Ohio-based Goldmeier Consulting, which specializes in Big Data analysis
and analytical tool development. “If you can think of several significant mistakes you made in the process, then you should accept the criticism and learn from it.” A key to this is keeping a cool head. Even if the criticism coming your way is unduly harsh, don’t respond with anger, sarcasm or defensiveness. Center on the important criticism and avoid wasting time arguing about personal issues.
Be the Savior
The sooner you can identify actual weak points in the project effort, the sooner you can rectify the situation. “If you turn the project around, you’ll be remembered as the project’s savior,” says Goldmeier. “Don’t let this opportunity to prove your leadership get away.” Take ownership of getting the project back on track: Take the lead in resolving its problems and pushing the team forward. The go-to person will be remembered for the effort’s success, not the bumps that were hit during the development process.
Don’t Point Fingers
Even if you don’t think you’re at fault, don’t play the blame game with your client or supervisor. “Chances are, you saw the red flags early on, but felt you had neither the confidence nor control to change direction,” observes Goldmeier. “Arguably, that’s contributory negligence on your part.” Instead, make your case about how to fix the situation in pragmatic terms. But don’t use the opportunity to make yourself look good at the expense of others. “Arguing that you are in no way accountable for the project’s current state will create resentment in others and is most likely not true,” Goldmeier says. But don’t go too far the other way, either. Taking full responsibility for a problem just to prove your leadership impresses only those who deserve the criticism.
Prepare for the Worst
When they’re talking about deadlines, IT people tend to be overly optimistic. So don’t fall into another trap and over-commit on what you can deliver, says Bryan Hogan, president of Afidence, a Cincinnati-based consulting firm. If you see problems coming up, advise your manager or client of the situation. “You might want to say something like, ‘I know I don’t have full insight on the project, but I can see issues in this area that I have to commit to.’” And be specific.
Acknowledge the Human Factor Software engineers
might be adept at the technical side of things, but the human element can often stymie them. “It’s one thing to upgrade networks, devices and servers, but it’s often end user impact that’s the big issue,” notes James Kenigsberg, CTO of 2U, a Landover, Md., SaaS solutions provider. If you’re talking about a CRM system or a core business application that integrates with other apps, you can expect some issues with the end user, he says. Even if everything else works, a project can still be deemed a failure if people aren’t trained well. Once the problem project is (finally) over, conduct a post-mortem. Establish a plan to address and mitigate problems that could happen on future initiatives. Mistakes should be learned from, so talk to team members and document them together.