The First of Two Articles –

Matrix management is not uncommon in larger organizations. Most of us have experienced its negative use – namely confused accountability and frequent moving of people from project to project resulting from poor management planning. Practice based organizations employ matrix management, yet the key focus leads mostly to improving the quality and capability of project teams. When executed with the following principles in mind, projects and teams yield significant benefits …

Practices are the various skilled facets of an activity necessary to accomplish that activity effectively. In software projects they include (but are not limited to) software development, architecture, data, project management, quality assurance, configuration management and infrastructure engineering. Depending on an organization’s needs, any number of other practices may be added, from usability (UX) to business analysis or deployment or customer support or …

Practice based organizations typically group specialist into practices either through direct reporting to a practice lead (and then individuals are matrixed to projects) or through practice groups which meet periodically to work on aspects of coordination and improving their specialty.

Practice based groups should be run by practice leads – people with deep experience in the specific practice. Along with that experience, they should demonstrate three other key attributes:

1. A proven track record for coaching others in their field.
2. An attitude of service, as the focus of the practice lead needs to be the betterment of projects that do not belong directly to them.
3. An outgoing personality, as the success of their practice largely relates to the lead’s ability to go out and understand the projects they serve and the people on them.

Individuals from practices should generally matrix into projects for long term engagements. Teams need to build stability so cohesion and productivity increases as the team works longer together. How does accountability work? Individuals matrixed to a project are operationally accountable on a daily basis to the project leadership, which includes their tasking and subsequent performance.

From a quality and competency perspective, the individual reports to the practice lead. It is the responsibility of the project leadership to ensure productive use of the resource. It is the practice lead’s responsibility to ensure that individuals on the projects perform admirably on the project, implement practice standards on the project and bring back lessons learned and best practices to be shared with others in the practice.

With that brief introduction, the following list reflects the benefits I’ve focused on when shepherding a practice based approach. I will continue with the latter four benefits in a subsequent article:

First 4 ( of 8 ) Key Benefits to Practiced Based Organizations

1. Everyone is a First Class Citizen

As a software developer for many years across many projects I often found that developers are the “first class citizens” and many of the supporting roles are second class citizens. Ask any QA person and they’ll say, “Oh yeah I’ve experienced that! Story of my life …” When looking at the maturity of software development teams, higher productivity teams typically know how to leverage more facets of the software development activities. Practices help the organization elevate the importance of the “other” specialists beyond the developers.

Practices not only provide a voice for QA or CM or … but also an advocate through their practice lead. For example if a QA person can not agree with the project manager as to the criticality of an issue with regard to a deliver/no deliver decision, the QA person is no longer squelched in a reporting hierarchy; they can speak with the practice lead who can intermediate and resolve or decide with their project management peer that the issue needs to be escalated for resolution.

Secondly, specialists tend to place greater value what they know more than what they know less. As an example, a project manager is more apt to focus on current impacts on budget, schedule and customer commitments. Quality and risk become the trade-offs in software design, CM shortcuts or QA issues for example. By establishing teams where the project manager is the hierarchical lead, one ensures that budget, schedule and commitment will almost always win out over any other issue.

2. Experts Hire Experts

A typical stove pipe team will have the project manager or project lead hire the team members for DBA, QA, CM, SA, et al. Of course any project manager or software development lead is likely to say, “I know what I want in that person.” Well of course they have an idea, and their needs are very relevant to hiring. But the reality is that few project managers have been a QA lead for 10 years; they are not expert in the field.

In a practice based organization, Practice Leads work with key stakeholders on the project team to staff the right people. This begins at the onset of the staffing cycle, understanding the project, its challenges and what kind of practice based approaches could be most effective. The Practice Lead will typically take lead for finding the individual and bring candidates to the team. Ultimately the hire needs to be agreed upon by the Practice Lead and key stakeholders on the project – everyone has skin in the game. In an organization with many projects, this approach can ensure greater practice quality and capability consistency across projects. For the project team it can provide higher quality candidates with an expert view of the project’s need from the Practice Lead.

3. Organizational Transparency

Larger software organizations struggle with visibility into projects and their activities. Visibility solutions are often mediocre and include monthly project reviews, milestone based reviews or worse yet senior management parachuting into projects when rumor indicates something is wrong. A yet worse solution is an audit group that independently communicates project activity. Modern day versions are smoothed over into PMO’s (Project Management Offices) and can ostensibly perform the same activity. These groups are typically fraught with, “those who can do, those who can’t police.”

The executive miss in organizational design is not understanding that different practices employ people with different perspectives. Project Managers message manage – it’s part of their job. Developers, most of them, will write more code if given the chance. DBA’s will forever find data problems in a world that is never quite perfect. These all have inherently positive contributions which sometimes also have negative side effects.

Practice based organizations recognize the value of all these activities and also provide multiple natural communication paths up the management hierarchy. In this way there is organizational transparency as well as a manner for resolution for different perspectives to occur through management peers in the hierarchy. For senior or executive management, broader visibility through expert eyes surfaces important opportunities and risks, versus canned monthly presentations or auditors or PMO members lacking deep expertise.

4. Birds of a Feather

It is not unusual for all but significantly large projects to be staffed as follows – several developers, maybe a data person (or two), a QA person (or two), a CM person (part time), one project manager, maybe an architect. Of course smaller projects have people performing multiple roles (e.g. dev lead is project manager and architect). But for anything but very large projects the issue I’ve consistently experienced is that developers often have one another to commiserate and problem solve. The other folks are onesies on the project. I experienced this first hand when I went from being a developer to a project manager. The only person I could really get perspective on project management was my boss.

With a practice based approach, specialists now have a greater community in which they can interact, build relationships, share in both challenges and successes. Without a practice approach, specialists could still reach across projects but may have to cross priorities and political boundaries. The practice approach facilitates community and sharing with specific activities intended to help connect its specialists, raise awareness of the activities across the organization and promulgate the state of the practice’s art.

(Click here to see Part 2 of this article)