What do you need to do to bring a software development project to a dead end?

Get a group of software developers and give them a manager who never managed an IT project before, but is a skillful oracle who can convince business users that his team is working as planned, is moving in the right direction, and will produce good results. Important: at any cost avoid setting any deadlines and deployment dates – not even for the alpha releases.

During the first year, the business users wouldn “t expect seeing improvements in software because the previous team lead used the wrong architectural principles, wrong design patterns, didn “t use Ruby on Rails. Besides, who said that creating a cross-platform state of the art software should be easy?

The biggest enemy of such project is agile methodology. No two-week sprints showing any intermediate results are allowed. Insist on the waterfall management style, which requires a couple of years just to produce the project documentation.

Software developers working for such manager will quickly figure out that they are allowed to spend most of the time working on their pet projects. But if Google employees can spend only 20% on pet projects, in this team it “s close to a 100%.

Our charismatic manager will keep convincing project stakeholders that the headcount and the budget for his team needs to be increased. One of the reasons for new funds is waging a new flame war with Java developers from the 15th floor. The goal is noble ndash; to explain them that since all software development on the 13th floor is done in Ruby and Rails, the 15th floor would also benefit from using this great technology for quick prototyping. Conventions over configurations rules!

A couple of years later, this war can be used as an excuse, “The war with the 15th floor created holes in our budget, so we could not complete own project and need more money rdquo;.

This manager would keep generating new internal projects. Massive code refactoring is a great candidate for this! Every developer will be able to convince any outside auditor why replacing this piece of code with that one is the right thing to do. Developers will do it sincerely and with high energy. No ROI? Well, you can “t measure everything with simple arithmetic. Restructuring the code and making it more readable is clearly a great project for future generations who may want to read and reuse our software components.

Unfortunately, the day may come when the business users/stakeholders will notice that in a couple of weeks they can run out of money. No, literally. Now this project will have to be either closed or outsourced to India with mandatory relocation of the entire team from Washington DC to Bangalore. All of a sudden, the angry business users will become hyperactive and will start putting enormous pressure to our IT team (they even force the team to work on the weekends, no kidding!). Dear business users, didn “t you see this manager was pulling your legs from day one? Or maybe you knew it all along, but wanted to enjoy seeing this incompetent C-level manager on his death row? You got it now. The project is terminated. Who “s happy?

The job has to be done anyway. Put up a new job description for another project manager, but make sure it includes the following clauses:

“Deep familiarity with the agile development methodology is a must. Successful large-scale projects must have traceable references with a proven track record. “