Well the simple answer is you probably shouldn't. What's absolutely required is a some form of consistent management framework that provides senior management the level of overall control they require, and the means of measuring project success, but this framework should be set at a high enough level not to constrain the people whose job it is to deliver. What they fundamentally need is the room to employ the best approach to meet whatever objectives have been set. 

For sure, in certain circumstances, a single process may do the trick, especially if the work is fairly uniform in nature, or there's a pressing need to bring order out of chaos. Processes provide a common terminology amongst development staff and having a consistent, stable approach can provide a solid platform for improvement. But where variety is the spice of life they can become a constraining force. Worse, if over zealous process police hold sway, the team can spend more time making the process fit, rather than focusing at the real problem at hand, delivery.

Another issue with imposing a defined process is that for some people, the process becomes a means for absolving themselves of responsibility. On more than one occasion I've heard quite experienced project managers attempt to explain away a bad decision by blaming it on the process. With the introduction of a new process, be it Scrum, RUP, or whatever, common sense can have a tendency to take a leap out of the window. For others, the process becomes the be all and end all, becoming the focus - and industry - in its own right.

This is beginning to sound like a rant against all development or project management methodologies and the methodologists. It's not meant to be. There's a hell of a lot of good thinking gone into developing many of the processes around to day, and without doubt the team will need a means of meeting their objectives and this means is the process, usually articulated through a project plan. But projects and programmes are, by their very nature, extended learning and discovery exercises, and as you find out more about the problem domain and potential solution the team needs to be able to adapt.     

So what's the alternative? Well the first point is that no single methodologist has a monopoly on good ideas. The second point is that if you're going to trust the teams to determine the approach they must be equipped to do so. So what's needed is to ensure your team is seeded by flexible set of experienced people, who've been there and done it on a variety or projects, and have been exposed to a number of different methodologies. What these people have built up is a toolbox that contains a whole set of techniques that can be appropriately applied to the problem at hand, and importantly the confidence to take charge. 

To illustrate the point, the table below lists some of the methods and techniques, employed on a recent project.  

For sure the blend may confuse the inexperienced, but developing a solution with an inexperienced team is not such a great idea anyway if you plan to hit deadlines and delivery quality product, and, in reality, all these things sort of fit naturally anyway and only become a problem if somebody decides to make it one.

So, if you're heading down the "single process fits all" route perhaps it may be worth talking a step back and working out if this is really going to meet your needs. If it does well fair enough, and there are some powerful arguments for taking that course, but if not, a different course would be to train your staff in a whole variety of methods and techniques, and empower them to choose where and when to use them. Add to this ensuring the team are seeded with some seasoned professionals who've practical experience of development and you're away. But don't forget that management framework, giving a team cart blanche to do whatever they want without any high level control is probably not the best idea if you want to control the risk and have repeatable success.

Last but not least, ensure the person at the top, responsible for delivery, is an expert in software development and genuinely interested in the methods and technology. You'll spot the well-thumbed books on their bookshelf. These people can sort the wheat from the chafe, encourage the teams to try new thinking, and reign them in when they get out of line.