During my career I have been part of a large number of projects, from small simple ones to large $100M+ complex projects changing the core of a customers business. Regardless of size, one thing that a lot of them seem to fail doing well is to define and communicate a set of guiding principles for the project.
Guiding principles for me are guidelines that help project members make the right decisions when faced with a choice. This could be to include or exclude a particular piece of functionality or leave a process as-is or redesign it to provide better value to the end users. Don’t get me wrong, a lot of the projects do a good job of managing scope, etc. but they don’t do a good job of helping project members make the right decision when it comes to how to solve a particular problem. If your project is small and very centrally managed, you may not need guidelines assuming the key decision makers are always there to make the right decisions but as soon as you create separate sub-groups responsible for a particular area it falls apart since each group will use their own idea of what and how things should be done.
Why this is the case I’m not sure. Maybe it is because too many organizations are too focused on managing rather than leading their people. To me, there is a big difference between being a good manager and a good leader. A good leader sets the direction and a good manager takes you there.
Sometimes a set of guidelines is defined but often they are too high-level and abstract, e.g. customer service above cost. Does this mean I don’t need to worry about either the implementation or the operational cost at all? What is customer service, increased number of interaction channels, less wait time or something else? Even though the guidelines are just there to guide members, they need to be specific enough for people to understand how to apply them to each problem they are faced with.
Another common problem is that even though the guidelines are defined, they are not communicated to the complete team at the beginning of the project. Either, they are part of a project charter document that only a few select people have access to or they are defined after the project has started. The problem with defining them after the project has started is that most of the decisions are made early in the process.
To avoid having people making the wrong decisions, I think defining a good set of guiding principles from the beginning, i.e. when you start building your business case, helps getting everyone on the same page. As project implementation starts, a more refined set may be necessary depending on how large the project is. Make sure you communicate your guidelines to EVERYONE on the project and make sure they know them by heart or have easy access to them at all times.
What is your experience? Do you have any good/ bad examples in regards to guiding principles that you would like to share?