aka you are not your project
In a lifetime of IT projects you are bound to be on one or more projects or even companies that fail. Projects, like companies, run out of cash, get beat in the marketplace, get starved for resources, and so on. What makes it difficult in large enterprises is that the bottom line of the company is so distant from where your desk is. Say your working a payroll system, or a the benefits website. Can you track your efforts to the bottom line? Its a challenge. Its a challenge for project management since the challenges are often beyond your control. If the company is cash strapped and it affects your resources, you have to continually replan. It usually has a few common stages:
1. Unreasonable deadlines or expectations are set - this is because the business is running out of cash and may need your project for cost savings or profit. They may need that doorstop to teleport small animals, when really it was only supposed to hold open the door.
2. Key resources are pulled or shared- its a common pattern to bunch together DBAs, Usablity, and deployment/build engineers. I get why this is done, but as a PM I still hate it. It kills the teaming and the ownership of the product that your creating when some dude 100 miles away is mindlessly running database scripts on yet another database. Its a manufacturing mindset for certain. Worse is when the deployment people aren't sitting with you or are on 10 different projects.
3. Once your key resources are pulled, things will start breaking. It'll take longer for your system to recover because all the folks who created it and truly understand it are gone. This will of course thrill your customers who are already setting the deadlines in #1. It won't take them long to execute #5, but not before they'res a good blood-letting via #4, the Blame Game.
4. Blame game - This is when the long knives start coming out. A few things might be good fall guys :
- The Process : Agile usually gets the blame at larger companies. Its really new and difficult and no one really wanted to do it in the first place. At smaller ones, the fact that there was no process gets the blame.
- The Tools: medium to large projects typically have some sort of new technology that they're trying to implement, typically with under-trained resources and unrealistic timelines. It was exciting initially and now everyone's looking for the guy who chose this dog.
- The People : Always part of the mix, since robots aren't writing code yet, who else are we going to blame? I've been caught up in this one. I told that DBA we had a deployment and he went fishing? What? That Cognos feller went to China? What?
- Communications: Of course this is the fall guy for everything, since its so difficult in large systems. 'nuff said.
- The Vendor: Easy target here. If the vendor or supplier wrote even one line of code its easy to bash on them. Its even better if its outsourcing since every hates that but everyone relies on it too. I love it when they say, " you know India is 12 hours away..." Was this a surprise to people after the contract was signed?
- The end user/customer - This one is tricky since the customer is usually the one paying for it or knows them really well. IT will blame them because they asked for Mars, but really wanted the planet and not the candy bar that IT delivered.
4. Your funding is pulled entirely. Despite the thousands of people hours and tens of thousands of dollars in capital, it occurs to people in the midst of a proejct, usually between the apex of spending and the trough of no ROI, that they could write this system for less, or they don't need it any more.
So, onto the Survival Tip #1 : Fight the Story.
What is in common with all the items above is that there is a story that will start getting attached to your project. Project A can't deliver. Project A has troubled people. The tech Project A is using is a career dead end and the wrong tech for the project. These stories will likely start with peers on other projects in an effort to rob your project of funding. Its Darwinian but its business.
To fight the story, you need to make sure where the decisions are being made. Find the gatekeepers and ensure that if your opponents are there, you're there. Think about merging with one of your competitors...after all they're just people trying to do a job, and ostensibly on the same side. Make sure you exceed the reporting needs, and do as much stats as you can.
If your successful Fighting the Story will slow the exodus of dollars from your project and people from your cause. In the next installment, I'll talk about how you as a project leader can survive personally and help your team do the same when things go from bad to worse.