Some time ago, I was working with a company developing security systems. The company’s new product generation was to have speech input and output in addition to the touchscreen interface on its line of small devices. Therefore, management had set up two user-interface teams: one responsible for the touch screens and one responsible for the audio interface. These two teams were located in different cities working off their feature lists without ever questioning the overall business process that the devices were meant to support. Looking at the project from the outside, one could immediately see that more discussion between the two would have led to a far better use of the two technologies. —JSR
Imagine that your company is awarded a new development contract and that you are appointed as project manager. You feel capable of doing the job since you have all the required skills and experience. You distribute the work according to the different skills needed, either among depart ments in your company or between your own departments and a partner company that is specialized in one of the relevant technical domains. You have capable subproject managers, and they take up their assignments with enthusiasm. The subproject teams are content with the work allocated to them, they understand the goals of the overall project, and they do a fantastic job in their domain. They do come back to you, but only for more time or money or other resource-related project issues. Your sub-teams work in different geographical areas, but you are not worried since the distribution of work among the teams is well documented. They formally cooperate with each other, negotiate interfaces, and share their intermediate results.
The customer offers excellent domain input for the subject matter, but different domain experts are assigned to the different subprojects. And sometimes these domain experts do not even know who among their colleagues is working on the other part of the same project.
At the helm of the project, you and the top manager from the customer organization work closely together to manage expectations and to track the progress of the many sub-teams.
And yet, your project is almost certain to yield a product that does not work very well in the eyes of its users. What’s wrong?
Your project has left one chair empty. Many projects fall short of real success for want of a single individual whose responsibility it is to ensure that the resulting business process—from the users’ points of view—works as well as possible. This person is interested in the best output of the overall project for the customer’s business—down to the finest details.
We’re not talking about a project manager, nor are we talking about the overall leader of the project team. This person may not have any direct reports, and he almost certainly is not also accountable for budget or schedule. His entire focus is on how the product will interact with its target environment, especially its users.
Such persons carry all manner of job titles: product manager, system architect, business analyst, and so on. Some call themselves technical project managers since their job is to care about the details of the solution (in contrast with the overall project manager, who handles budgets, staff, and schedules). Regardless of the title, these people are not part of any sub-team; they work across all sub-teams.
It may be sufficient to have such a person only on the customer side. If somebody from the customer’s organization constantly questions the synergy of the subproject, you may succeed, even if the teams on the contractor’s side lack any similar unifying role.
The empty chair is even more often found in projects chartered to integrate already existing products. Here, the technical aspects of integration drive the project while details of business integration, ergonomics of user interaction, and creative ideas that could lead to breakthrough synergies are ignored.
Take a look around your project team’s table. Is there an empty chair?
Win a free pass to the BA Conference Europe, London, September 22-24, 2014, normally costing £1374 to attend. This competition is sponsored by Volere and the Atlantic Systems Guild Limited.
Read Tom DeMarco's article from the July/August edition of IEEE Software: Sigil, BlueGriffon, and the Evolving Software Market.
"This war isn't going to blow anything up, only turn everything off."
Announcing the publication of the third edition of Tom DeMarco and Tim Lister's iconic text, Peopleware: Productive Projects and Teams. The book is available now from Amazon or directly from Addison Wesley. See press release on Business Wire.
Read Tom DeMarco's essay from the July/August issue of Software Magazine. It's entitled, Bells, Whistles, Power, and the Requirements Process.
The preparation course for the IREB "Certified Professional for Requirements Engineering" is now available as video training. Learn at home or any other place. Including questionnaires to prepare you for the multiple choice test.
A Sci-Fi novel from Tom DeMarco: Andronescu’s Paradox. Could this be the Apocalypse we’ve all been dreading? Or has the nineteenth century just returned for an encore? Click to find out.