10 Common Issues for Architects In Requirements Management

I wanted to share some common issues I see when managing requirements in large projects.

1. The blur between the Architect and Project Manager

Architects build architecture solutions, and if you read standards like ISO42010 its quite clear that designs have to meet the needs of the stakeholders and clearly stake how they do it. This means to design optimal solutions its architects that need to manage requirements. Project managers are there to track, report and guide project state. They naturally have an interest in making sure requirements are met, on time, on budget. Because of that drive I have sometimes seen project managers driving the requirements and their allocation. A good project manager complements an architect, and does not overrun them. The responsibilities between these two roles should be laid out clearly.

2. No project lead architect

In big projects with more than one architect there should always be an architect who is guiding the work of the other architects – to ensure that the different architects and teams are building to a common vision. Depending on the scope of the project that architect might be an enterprise architect or a solutions architect for example. Just because the lead architect is responsible of the solution doesn’t mean the architect cannot use other resources to help with the initial analysis. Large projects should not start without a lead architect coordinating parts, because costly mistakes can occur.

Keeping the vision on track

If you give three children three piles of Lego blocks they can end up building three different things, like a car, a giant chicken and a space ship. All great things that could be built with the same Lego blocks, but if the original idea was to build a house with a garage and car…. then you have problems. The same is true of requirements – three different architects can realize the same requirement in three different ways.

Inefficiency in design

Very often if you are running in large projects there are opportunities for synergies, and to avoid duplication of work in the design, and duplication of components in the resultant design. If one team is designing a platform for database servers, and another team is designing the solution for application servers, there are some opportunities there to reuse common elements to keep costs down.

When working in an organization with silo’s its quite common for separate product or service teams to have separate approaches to things like monitoring. If we are designing and overall cost and profitability are a concern at this point a lead architect should be looking at the feasibility of simplifying the solution. That could include talking to different architects that run the standard services. If 2 services use two different monitoring solutions, you have more complexity & more licensing costs, and need more people to support it. There’s also more things that can possibly go wrong. There’s not always a possibility do optimize down but at the very least those product service architects should be aware that such possible synergies exist.

3. Inconsistent requirements through text analysis.

If requirements are not given and have to created by analyzing text, or speaking to people its important that an architect creates a requirements list. if you do not work from one common set of requirements every paragraph of text is open to interpretation, which can lead to an inconsistent solution. An interpretation of text should be written down and agreed.

4. Unclear requirements

Sometimes requirements are vague or open to interpretation. In this case those requirements need to either be clarified by talking to the source of the requirements, or clearly documented assumptions need to be made, if for some reason there isnt an option to clarify with the source. Assume makes an “ass” out of “u” and “me”.

5. Pick your own requirements

In some projects I have seen an approach where a big requirements list exists that project managers ask the architects to pick the requirements that are relevant to them.

This needs to be done with caution. because several problems can occur. Firstly its possible that some requirements will not be managed unless the project manager is sharp. Secondly in taking this approach you can end up with an inefficient design. A good lead architect will look at all requirements together, and in understanding the principle needs of the solution will design and assign out responsibilities, and as I mentioned already will make sure that we have efficiency in our ways of working.

For example if we are looking at building a secure hosting solution and we have principles around layering security – to ensure this happens it may be that a specific set of requirements are given – and in order to get consistency throughout the whole design extra requirements may also be defined.

6. Not considering requirements hierarchy

Every project is a combination of customer requirements and internal requirements, and there needs to be a structure for requirements management to avoid a lot of conversation overhead, and to ensure we have efficiency in design.

Typically the business and customer are the priority. I like to use BDAT – Business, Data, Application, Technology as a priority. The hierarchy should be clear.

In the past i have seen service architects that are responsible for standard products in an organization say “no” to the business. Sure this can be done, but it comes at a cost, because if we cannot use standard products suddenly the cost of a solution gets a lot higher with customization. It needs to be clear within an organization that service architects are not there to say no – part of their job is to adapt standard services to meet customer needs over time. Architects have areas they are responsible for and they should be providing solutions and not problems.

A second part to this comes in when we look at the relative weight of requirements. If one requirement has to be met by three separate teams then of course each of those teams have a responsibility to show how they realize the requirement in their design, but the requirement should be managed at a level above – by either the lead architect or someone they delegate, to ensure that the realization of the requirements in design are done in a consistent fashion.

7. Unrealized Requirements

ISO42010 says something to the effect that every architecture concern needs to be framed in one or more architecture viewpoints. Effectively we are saying that every requirement needs to be handled within a design. So the design documentation needs to show exactly what is done to meet every requirement.

8. Forgotten requirements

If you are creating a solution from a request for proposal, its very easy to focus on those requirements, and not think about other requirements from other stakeholders. When building architectures we normally have a number of internal and external stakeholders, and we may be thinking about ITSM tools. When we are properly modelling motivation layers this risk can be reduced.

9. Forgotten principles.

When designing an architecture solution principles need to be applied. Often principles are given by either the organization or the customer, but sometimes when looking at requirements a lead architect will see the themes within the requirements that are given. For a good quality resultant solution it may result in project level principles that are to be considered throughout.

10. Not managing requirements

Requirements need to have a responsible person managing and owning them. in determining how to realize a requirement this is done as part of the requirements realization but also there’s a dialog that is happening between different stakeholders in the requirement. Its very important to keep track of the key decisions that are taken, any assumptions that impact the requirement, as well as the people that have made these decisions. Its something that can be key to understanding why decisions are taken in years to come.

Summing it up

You can probably see that managing requirements properly, especially on large scale projects is not an easy task – and to do it in the best way requires a good interaction between both project managers, and different architecture teams. Having a good requirements management process is not only key to ensuring projects are performed well, but also impacts the overall quality of a resultant architecture in project design.

Good architecture leadership can make or break a project.