“Management just doesn’t get it!”  I can’t tell you how many times I’ve heard these words from friends and colleagues about projects they were working on.  How do the people working on solving problems in a software project get so disconnected with other people (sometimes management) who are solving different problems in the same project?  Of course, there will always be the uninspired employees and leaderless management, but this problem goes beyond these folks.  Although my perspective in this article is mostly on software projects, the challenges and situations apply to all project domains. 

In order to explain this situation, it’s important to consider where the software industry has come from and how it’s evolved over time. 

At some point long ago, scientists realized that electronic machines were very good at dealing with information and changing information based on code they wrote.  These scientists knew their scientific domain and with a lot of effort learned how to instruct machines to operate on their data in order to test their hypothesis and make conclusions.  In a sense, they played all the roles in a software project.  However, most importantly, they were both the developer and the customer.  There are two interesting things that are true of this simplified software process:

1. An extremely iterative process was used that allowed them to evolve the software to support the desired result.  If something needed to be changed to support a scenario (or type of problem) they were targeting, they would change the software.
2. The end user (which happens to be the developer and the subject matter expert) is very open to learning new, potentially non-intuitive, user interfaces in order to solve their problem.  These folks were accustomed to learning their way around machines in order to solve their problems.  In fact, they were forced to learn very primitive computing interfaces provided by the machines of their time.

As the Personal Computer (PC) industry grew and made PCs pervasive, more and more people realized that software could help them in business and their daily lives.  The difference with this new audience of software customers was that they were not willing to change the way they worked to experience the benefits of software.  This is the classic chicken and egg problem.  In this case, the folks who were knew to computers didn't really know how good they could have it.  To unravel this problem, software needed to move from its lower level concepts and interfaces (previously used by the scientists) to the concepts in the business domains where the new customers solved problems.  Additionally, it was this innovation of making software that had the same concepts these business and consumers were comfortable dealing with that created the efficiencies. 

This was not a change that occurred immediately, but it certainly was one of the main reasons why software teams grew to the size and diversity of roles you find in them today.  The responsibility of being accountable for each area, and becoming an expert in the area, exceeded the abilities of a single person.  Some of the other roles, besides Developer, are: Tester, Architect, User Experience Architect, Business Analyst, Project Manager, Program Manager, Product Manager, etc…  In fact, larger software projects not only have diversity in roles but also have a diversity of perspectives on each role.  When the Development Team responsible for building the code reaches about 4 people, it’s important for someone to be accountable for the higher level requirements.

One of the great complexities in project teams arises from complex communications. 

It occurs when two people working on the same project, who are trying to reach the same goal, have a miscommunication that results in a negative situation for the project.  Remember, communication is about providing context to others in order to convey a message.  A miscommunication occurs every time someone presents context others don’t understand.  How often do you think a Developer (for whom the world revolves around code and algorithms) provides context to a User Experience Architect (for whom the world revolves around user scenarios and cognitive models) and they don’t understand each other?   This is no different than considering the types of trade-offs a low level engineer and a high level manager make on a daily basis.  In fact, these two people use and speak different languages.

The solution to this problem is to analyze the interactions between people at different levels of communications and create Scenario Oriented Software to help people work towards the common goal.

In the Software Engineering domain, Visual Studio Team System provides two out of the box methodologies that define what roles need to be filled in a software team and how these roles interact over the lifetime of a software project.  These methodologies define the entities each role operates on (especially the Work Item Tracking system that manage instances of these entities) which enables the project visibility and accountability that continuously allow team members to assess the health of the project.  Some examples of these entities (or Work Item as they are called in Visual Studio Team System) are: Bug, Risk, Scenario, Quality of Service Requirement.  Because no two project teams operate the same way, Team System allows teams to customize these methodologies to fit the goals of your team.  Once a team customizes these methodologies and makes it their own, it becomes an evolving asset that enables continuous improvement.

On the visibility side, Visual Studio Team System has three mechanisms: reports, queries, and events.  Reports provide visual snapshots in time of a project’s state from many different perspectives.  Queries allow you to mine into, open, and finally operate on Work Items.  Events send email to team members based on rules set in the eventing system.   Together, these mechanisms keep each member, regardless of role, connected with other team members and their project.