The Invisible Project Manager

Traditional vs. Agile Primer | Upside-down Leadership
The fundamental principles of Agile and XP methods for delivering software are well suited to the notion of an Invisible Project Manager. In a more traditional model, the Project Manager is responsible for everything, including detailing estimates of the technical work, managing the customer, assigning tasks, tracking, monitoring schedules and directing the movements of the team. All of which is managed closely against The Plan and reported back through the regular channels. Conversely, the Agile approach brings the customer and developers as close together as possible, asks the customer to prioritize the work, the developers to estimate the work, and then facilitates the negotiation between the two sides. And while all the regular aspects of a Project Manager's job description are still met, the manner in which they are done is quite different.

Trust Me | Information transparency from the outset
Building an open and honest environment is a key challenge for any project manager, and needs to be positioned from the start of any project. The earlier the better. Information that is disseminated in a way that improves the lot of the entire team will result in members being less worried that important details are being hidden. Once this tone of transparency is set the trust factor within the team will creep upwards, to the point where team members will implicitly trust the Project Manager. This is optimal, as it allows team members to concern themselves with the tasks at hand, not worrying about what surprises lay in waiting.

In practical terms, this means a high bandwidth dialogue amongst the team and stakeholders facilitated through a whole series of channels - stand-ups, retrospectives, big visible status reports, informal conversations, and an attitude of encouraging others to bring forward issues.

This practice can be compared to Continuous Integration, a key element of Extreme Programming. With Continuous Integration, as soon as a piece of code is written, the developer checks it into the repository where a full suite of tests is run against it, and immediate status reports are given (ie. the build breaks/passes). If the team is able to do this multiple times per day, the risks built into the project when it comes time to release the code are hugely reduced. In essence, paying a little pain each day to remove the oft-maligned integration bear lurking at the end of development.

As a project manager I want to ensure that the same principle is applied to team progress, problems and reports. As often as possible, I want to hear the ‘bad' news about delays, surprises, failures, and achievements, so I have an accurate read on reality. By radiating this throughout the organization, without drowning constituents in information, the risk of a significant surprise facing the team is negligible. More so, virtually all problems are solvable by the team - if its given adequate warning and the space to do so. By trusting the broader team with all the facts, adjustments will naturally occur, and the road will completion will be much smoother.

Big Eyes, Big Ears | Listen, watch, think; then act
Managing a team of people is very much a real-time activity. Plans do not manage people; people manage people. Popping in once and a while to see how the team is doing does not qualify as being involved, and without someone to help liberate the team from hurdles in its path, its prone to getting caught up in things that aren't meeting overall objectives.

Ideally, the project manager will sit with the entire team. With eyes and ears open to what's happening, information is gathered rapidly, then, with some thought, decisions and actions are taken. Often the right action is very small or subtle, but hugely effective because the timing and context are accurate. Nudge. Suggest. Ask. These are much better tools than Force, Demand and Tell. If two or more teams are involved, then sit in between them, or at worst, in each of them a proportionate amount of time. The fluidity of the requirements and solutions of a complex software project must also be mirrored by the management style.

Facilitate amp; Coach | Let problems solve themselves
Within each team, there are technical and domain experts that ultimately put the right solution together. The measure of a project's success is not whether it kept close to its plan; it is whether the hands of those involved delivered business value. Accordingly, it is acceptable for the Project Manager to not know the answers to all kinds of questions. The Project Manager needs to work on bringing those solutions from the minds of everyone involved, and all the while keeping an eye on what people like to do, are good at doing and are supposed to be doing - if all three of those parameters are aligned, productivity will be unleashed.

Facilitation means getting the right people to talk to each other, helping a group draw out a conclusion, or breaking down internal barriers in the team. This coaching role focuses on the needs of individuals and elevates them by dolling out more responsibilities, talking through problems, or just plain cheering when people are making stuff happen.

Making Yourself Redundant | Systematically building teams
Projects, like companies, work best when a system is in place. And ‘system' is not to be confused with ‘defined process.' A system means a way of doing things that is not wholly dependant on a specific person. Reference the old ‘hit by the bus' test. Indispensability is the nemesis of a system. Key, irreplaceable and rare people are huge risks, as well as generally quite expensive to find.

The thinking must then be on developing redundancies throughout the team, per the spirit of Agile, and breeding generalists. This should extend to all functions of the team, including that of the Project Manager. Obviously, if the Project Manager is away for several weeks, a proper replacement should be brought in to play the role, however, missing a day or two should not bring the team to a halt. Leadership and management can be spread out into other people, and if all relevant information is radiated, or at least available to the entire time, then bottlenecks are mitigated. Typically, pairing is used by developers to promote knowledge sharing, and there is no reason why this principle can not be applied to all roles on the team in the name of building something that does not have a single point of failure. A sharp Project Manager should watch what happens to the team when they, or others, are not available. The cracks that emerge in the team provide guidance on where weak spots in the team exist, and thus opportunities for improvement.

Collective Ownership | Destroy Ego;Spend Credit
Traditionally, the Project Manager was considered the single point of responsibility for the fate of a project. Naturally, this led to behaviors that put the livelihood of the Project Manager ahead of the team, as neither the glory, nor the failures, were shared too broadly. However, to drive the most out of the team, a real sense of shared responsibility must be instilled in the team, and understood by senior management. The Project Manager can impact this by destroying ego, and spending credit.

This does not mean downplaying individual achievements or giving them to someone else, as this will result in mutiny. It does purport that by sharing the rewards of success, and the lessons of failure amongst the team, members will put themselves on the line to drive the project. This sense of ownership is built into the team over time, as the Project Manager heeds the need of their ego, for the collective wisdom of the team, and redirects credit accordingly. The proof of this comes in times of stress, where instead of stepping back and letting the Project Manager deal with the fall-out, they take responsibility for their project and do what is necessary.

Motivate and Shield | Clearing the tracks
Imagine the team is a big old steam driven train, barreling along the tracks. Getting this weighty beast up and moving takes some time, but once it is rolling, its momentum becomes self-sustaining. The Project Manager's focus can then move from stoking the engine (early stage of the project, and focus on internal activities) to laying track and ensuring the train has what it needs to keep the pace (external focus).

The Project Manager's challenge is to create an environment where the craftspeople can flex their talents, create solutions and solve problems. Team member typically want to excel at their respective craft, and this natural source of energy needs to be harnessed. However, the entropic forces surrounding any organization often trip up the best intentions of any team - bloated meetings, unnecessary paperwork, switching projects, and other distractions all cost the team dearly.

Some of the most productive time comes either before or after regular work hours, and this is no accident. Meetings are scarce and no time is spent keeping up appearances - just a clean, clear focus on the work at hand. Keeping this vision in mind will help shape a more productive team environment during standard hours, and negate people from staying late simply to get their work done.

Delivering business value | The buck still stops here
While all of this decentralization and systematic team building sounds very progressive and enlightened, the fact remains for the Project Manager that delivered business value is the final score. This approach to project leadership needs to be viewed as such - an approach; a set of tools and techniques to get things delivered. It is not an abdication methodology that allows the Project Manager to throw their hands in the air and say it was the team's responsibility to deliver. However, the most effective way to deliver maximum results is by creating a truly high performance team that wants to spend its time eating through requirements. And a team that pulls the project is far more capable of achievement than one being pushed single handedly by a Project Manager and a list of tasks.

The Project Manager will always be a key role in a team, but far from the only one. By using these principles the Project Manager can facilitate a symbiotic relationship of shared goals that enables a diverse set of professionals to work together and create something bigger than any single person.