From an early stage in my project management career five simple principles emerged that seemed to me to maximise the chances of successful delivery. Remove any one of them and the chances of failure double, more than one and it's time to down tools and go home.

The five principles are:

*    Employ a good team

*    Provide clear, consistent direction

*    Removing constraints

*    Give them with the tools to do the job

*    Let them get on with it

Of these five principles the most important is the first. Good teams are made up of four basic ingredients: highly skilled people, mutual trust, excellent communication and experience. Given these ingredients the team has what it takes to work together to develop the best approach to solving a given problem. This is crucial as the software development process is one big extended problem solving exercise.

Clear, consistent direction comes next. People - teams - have to be clear about what they're being asked to achieve, and as crucially, why. If they understand the whys they can apply their skills and experience creativity, very often producing a solution much superior to that originally envisaged. As the days and weeks slip by the direction can get lost in the noise of day-to-day activities, so goals and objectives need to be constantly re-enforced "It's the economy stupid" is an example that readily springs to mind. Even better ensure the team has simple, short-term objectives - six weeks at the most - steering them towards the overall goal.       

Removing constraints covers a multitude of sins: unachievable timeframes, ridiculous performance targets, inappropriate processes, inadequate environments, poor access to end users, inflexible roles, to name but a few. These constraints sap moral and kill productivity. Software development is complex and the team has a difficult enough job to do without tying a hand behind their back. The project manager must work diligently to identify constraints, question old traditions and challenge false assumptions, bulldozing away anything that stands in the team's path.

Without the right tools it's impossible to build anything of quality, so ensure that your team has all the resources they need. This should not be limited to technical tools, the teams shopping list should include: access to domain experts, access to specialist resources (DBAs, usability consultants), a dedicated team area, books, internet access, whiteboards, projectors etc. etc. The better the team is equipped the faster they can deliver, and the faster the better because every day delivery is delayed is a day that benefits are lost, especially crucial where first mover advantage is key. 

So by now we have an excellent team, who understand what's required, have the tools to do the job and a clear path ahead, which leaves just one opportunity left to screw it up, overbearing, I know best, heavy handed, micro management interference. The role of the modern manager is to agree the objectives, take away the constraints, step back and hold a watching brief. From a high vantage point the manager can see who's struggling, what's not working and what's lacking, coach, mentor and support the people who need it, and choose their intervention points carefully. God knows It's difficult, but if you can resist the temptation to revert to command and control during those first crucial few weeks, after the inevitable slow start, the team (if it is a team) will begin to build momentum and accelerate away. 

A key point of note here is that I've not mentioned process once, and this comes from someone who has implemented software development processes at four organisations. Processes provide structure for development but their place is at the high level rather than down in the guts. Down there, imposing on people a single process to slavishly follow constrains rather than adds value, projects are just too complex for this. Instead good development professionals should come equipped with a toolbox of different techniques from which they can select and adapt, as the need demands.

Before we end, lets return to our first principle - employ a good team - and examine what happens when you don't have highly skilled, highly experienced people? For me it's a familiar story of: misplaced faith in processes and standards, inflexibility, defensiveness, slow (or no) reaction to changing circumstances, no suggestions when the current approach fails to work, poor decision making and ultimately failure. What's interesting is that one misplaced person can cause havoc, especially when placed in a position of power. In one recent example a failing programme was completely changed around by exactly the same team that had managed the programme from its inception, with the exception of one individual.