Requirements: Project Management or Architecture?

Having relatively recently earned my PMP, I have spent considerable time learning and practicing the science of project management. One of the key topics within the discipline, especially when discussing the scope, is requirements. I have also finished a solid year of research on architecture, which culminated with a reading of the TOGAF v9 specification, and there is much said in architecture literature about capturing and managing requirements. As I am attempting to formally establish an architecture practice at Liberty, there have been several questions around whose responsibility it is to manage requirements? The project managers think, for good reason, that requirements management is their responsibility. But having read TOGAF, especially the ADM, I am convinced that architecture also plays an important role in identifying and managing requirements. I think, like so many things, the ownership depends on the practicing organization’s structure and discipline. Below are some of my musings on how requirements responsibilities are worked out in three types of organizations.

Organization 1: No Formalized Architecture

In this organization, there is no formal architecture practice. This means that there is not a department dedicated to architecture and planning within IT or the broader enterprise. It also means that while there might be individuals with the title “architect,” there has not been any structure linking their activities directly to project work. In this organization, those who manage change efforts have the title “project manager” or something similar, and are functionally responsible for requirements gathering. As project managers, PMI has outlined several tools and defined outputs of requirements management, and while I take some issue with the lack of clarity expressed through the PMBOK around this topic, these are definitely good starting points for any project manager.

Requirements Management from PMBOK

1. Tools
   1. Interviews
   2. Focus Groups
   3. Facilitated Workshops
   4. Group Creativity Techniques such as brainstorming, mind mapping, Delphi
   5. Group Decision Making Techniques
2. Outputs (Documents)
   1. Requirements documents
   2. Requirements Management Plan
   3. Requirements Traceability Matrix

Organization 2: No Formalized Project Management

This organization either does not have any project managers or has not formalized its project management practice around a repeatable discipline. Liberty University’s IT division has been transitioning out of this type of organization for the last few years. While we have had project managers for as long as I’ve been at LU, there has been a high degree of variability between the tools uses, processes followed, outputs produced, and ultimately quality of delivered project. For us this has meant that when the project manager wasn’t collecting good requirements, others have led the charge. Most often those people were the lead engineer or that engineer’s manager. The justification for this has typically been that in order for the engineer to produce a product or solution, he needed solid requirements. On projects without solid requirements from the project manager, they were stuck doing it themselves. While according to PMI, this isn’t ideal, I am not convinced that this is always a bad thing. As I have researched architecture, I have seen that there is often a person who bridges the gap between the contractor (project manager) and the customer. We weren’t calling that person an “architect” at Liberty, but in most mature organizations, it would appear there is almost always a back and forth between project manager, customer, and architect. I think that while we’ve made strides at maturing one role – the project manager – in that triumvirate, I think the maturing of architecture development would have had equal, if not greater impact on requirements gathering.

I think this for two reasons. First of all, in most cases the architect will have skills that the project manager does not have. For example, I have worked as a software engineer and developer long enough to recognize the value in rapid (or even paper) prototyping; that in doing so you provide a quick view into what the end product could be? The chief purpose of which is to assess, refine, and collect additional requirements. The project manager in most cases, unless they are moderately specialized, will not have the ability to produce these prototypes. I believe this would and should fall on the architect. Secondly, it is evident from TOGAF, that gathering and rationalizing requirements is a central aspect of their ADM. Therefore, I believe that in organizations where there is no formalized project management, leadership should invest in staffing and training both project managers and architects. And, in the instances where these organizations already have architecture as a formalized discipline, I would wonder if they are not also functioning as project managers? If this is the case, then having architects trained in formal project management might provide even more benefit than staffing a separate role.

TOGAF on Requirements

http://www.opengroup.org/architecture/togaf9-doc/arch/chap17.html

Organization 3: Both Architecture and Project Management

In this organization, there is at least an attempt to have a formalized discipline for both architecture and project management. Requirements gathering activities for projects in Organization 3 should be the duties of both the project manage as well as the architect. This implies that there is an architect assigned to every project. I believe this is a critical point – if an effort is sufficiently large or complex such that it merits a specific project manager, then I believe that it also merits a specific architect. This might mean that some efforts have a project manager who is able to perform the duties of an architect and it also might mean that some projects are managed by architects.

My Thoughts…My Conclusion

I recognize that this blog is less scholarly than others and that my opinion is relatively meaningless when it comes to experienced architects, but I definitely am keen to the idea that architects do architecture well and project managers do project management well and that both should be committed to the act of requirements gathering. If projects are to successfully meet customer expectations, then they must do so through solid requirements gathering and management. I close with this quote from The Atlantic Systems Guild, Inc. on Mastering the Requirements Process,

Requirements are the most misunderstood part of systems development, and yet the most crucial. Requirements must be correct if the rest of the development effort is to succeed.

Advertisement