You’ve probably been there, working to deliver on one of those unrealistic schedules.  They all roughly follow the same trajectory.  The marketing team sponsors the next project with a must hit inflexible date, an inflexible set of must have requirements, and an inflexible fixed budget.  As the software manager responsible for delivering the release, you attempt to bring some reality to the situation, but you instantly conclude it is hopeless: there’s no changing your circumstances, and if you continue to try, it will only harm you. 

This is when many mangers make the fatal mistake: they immediately start the team coding.  There is no time to plan, no time to document, no time for meetings, no time for reviews, and no time for unit testing.  There is only time to code it, build it, pass it to QA for testing, find defects, and repeat the process until the release date. Then, someone makes a decision to either release it as is or slip the date and apply more pressure.

In this model the software manager has two primary responsibilities.  One responsibility is to apply more pressure on the team to work longer and harder.  The second responsibility is for the software manager to assume the role of fireman (hero):  wait for problems to surface, hold a meeting, give orders, and make decisions – hopefully good ones.

Once a project is in this mode and continues to work in this style, each release becomes ever more difficult to deliver as the code base becomes more fragile with every release.  Further complicating the situation is the high rate of team members exiting the company.   You’re losing your best and experienced people. You’re in the death spiral.  How do you fix it?

Prerequisites

To break the cycle, this product requires one manager with the authority, accountability, and responsibility for the success of the product delivery – a manager willing to make changes and consequently putting themself at risk for the good of the team and the product.  Working a team to the ground is often enough to keep your job even when things go wrong because it looks like you did everything to make a success of it, but it is really only show.  The team needs to work smarter and differently, and if you’re decisions don’t result in success, you will be the blame for it.  If you can’t handle that, well then nothing will change. 

It’s said a chain is only as strong as its weakest link.  In this role the software manager is that link.  The success of this delivery is dependent on the manager’s leadership as the manager sets the direction for the team and has the final say on all important decisions.  The manager is the only role with the depth and breadth of influence to affect the outcome measurably.

This manager needs to be responsible for both the Software team and the QA team.  Think of this like a football team.  There’s one head coach, and the head coach is ultimately accountable for the success of the team.  While there is an offensive and defensive coach, the head coach can overrule the decision of the subordinate coaches.  The head coach sets the strategic direction for the team.  He is the team leader.  Likewise, the software manager needs to be the ultimate team leader.

This manager needs both good technical skills and project management skills. The technical skills are required to know that problems are being solved appropriately, and if not, the manager needs to be able to mentor the team and provide technical direction.  There is no time to lose in making big technical errors, and the manager has the primary responsibility for preventing big technical errors. If this manager cannot assess whether solutions are appropriate to the problem domain then weak solutions will surface too late in the project lifecycle.  There simply is no time for late discovery of bad solutions that will adversely impact the delivery.

The lead manager needs excellent project management skills.  This manager should write and track the schedule.  The person who writes and tracks the schedule has the pulse of the delivery.   Having the pulse of the delivery is important because time is on your side early in the project, and with it, it permits you to make decisions early that will help secure the delivery.  The person who controls the schedule controls the team and secures the delivery.

I’m not suggesting there aren’t other important leaders on the team – there are.  The lines of command and control need to be clear and unambiguous for a difficult task to succeed. Like in a football game, the quarterback is the offensive leader on the field; the linebacker is the defensive leader on the field; the quarterback takes direction from the offensive coach; the linebacker takes direction from the defensive coach; finally everyone takes direction from the head coach.  Communication lines and responsibility is clear to everyone on the football team.  The software team requires similar leadership to get out of this jam.

Nobody has only one job responsibility on this team; any task required to deliver the project can be performed by anyone on the team.  If you need developers to test, then they put their QA hats on to test.  If you need them to write documents, then they write documents.  This is a team effort, and there is no room for prima donnas on a team – especially one that is delivering on a tight schedule.  If people are truly committed to team and teamwork, they should have no problem with this.  It helps to view our jobs a little differently in this environment.  Our jobs are bigger than software developer or QA tester.  Our job is to deliver a great product to market. In doing so, all the talents of the team may be required not just the talents narrowly defined by job titles.

Summary

A primary requirement for managing an unrealistic schedule successfully is good leadership.  Some organization structures are not well suited for managing through this problem successfully.  The PMO organization is often not well suited to managing through this problem domain as its decision making approach tends to be inefficient, and their often is a leadership void as the Project Manager often doesn’t have the authority to lead the team.  Further, team members are often working on multiple projects in a PMO structure, and fragmented attention adds further challenges to delivering on aggressive commitments.

Teamwork is also a very important requirement.  It’s the purest form of teamwork that’s necessary.  The kind that asks, “boss, what do you need me to do to help make this project a success?”  When you have great leadership paired with great teamwork, the impossible often becomes possible.