There are times when your gut instinct tells you that a solution is wrong. The architecture or design is not clean, functionality seems to be in the wrong place, interfaces feel like they should be different, data is duplicated or tramped all over the landscape, the solution seems too complex, it appears inflexible, it seems to be storing up problems for the future.
However, convincing people that there is a problem and that an alternative approach is better can be difficult. The project or program has a momentum that is carrying it towards the creation of an expensive and avoidable legacy.
Before we consider what you should do let us quickly clarify what not to do! DON’T…
Now let us look at how to move forward…
The first point is that within a project you don’t normally have much time. You must be focused, effective and efficient in substantiating your gut instinct, preparing and delivering your argument to the right people, and getting a project to reconsider its course.
Step 1: Determine your goal
Find out when key decisions are taken, when the project becomes committed to a course of action (e.g. contracts get signed, resources are assigned, work starts, announcement are made, egos are on the line). This determines what you can achieve:
Step 2: Understand the business drivers
Its all about benefits… what are they? Are they increased revenue, reduced costs, keeping up with the market, reputation protection, risk reduction, regulatory or statutory changes? When are they due to be delivered? What has been promised to investors? Are there any regulatory or statutory deadlines? Whose ego is on the line?
The business case for a project is the obvious place to look. However, business cases should paint a prudent picture and are written to overcome a hurdle in the investment process. Expectation could be significantly different, there may be other hidden or implicit or intangible benefits that are much more compelling to the key stakeholders. Understanding the business sector and the stakeholders is key to getting a full and accurate understanding of business drivers.
Timing of benefits delivery is often a major driver for compromise. If your proposals are perceived to reduce the level of benefits or put the timing at risk, then you will probably lose credibility.
Step 3: Understand which business drivers are threatened
I was lead architect for a project where we were introducing a new channel for a client. I felt very uncomfortable in taking the current architecture forward but I couldn’t pin point why.
The simplest solution to introduce the new channel was to extend the current solution. However, it felt like functionality was incorrectly distributed between applications and we would be making things worse.
What I needed to do was to identify the impact on the business drivers. I knew that the client was growing this part of the business but there was no clarity over how it would do so.
I knew how the application should have been built, I new how I wanted to take it forward. I could only make a vague case about enabling future business flexibility which would add cost and risk to the current project.
I managed to find a stakeholder, after much enquiry, who was prepared to very forcefully articulate the future direction of the business. He wasn’t particularly senior, he was not a key decision maker, but he was respected and influential. He was very interested in the threats to this future and was prepared to sponsor a rethink.
I struck lucky which enabled me to challenge (via a proxy) the accepted thinking and get rational compromise to be made and a longer term roadmap to be developed.
If you can’t make the case, then you have to accept the solution as is and move forward.
A word on architecture principles…
Each principle should have a rationale that is clearly based on business needs. If a solution violates a principle then look to the rationale to identify the business imperative that the principle is designed to support. While the principle may not interest many stakeholders, the underlying rationale should do.
Step 4: Understand the stakeholders
Architects often raise concerns where the longer term flexibility of solution has not been thought through or where a solution appears to cause problems in another area of the organisation.
As a solution architect, your responsibility is to ensure that the right solution for the organization is defined. “Right” is defined by the “business” – however, the “business” is an ambiguous concept. The justification for all architectural decisions must be “to meet business requirements”.
The key to resolving the architectural concerns is to involve all affected stakeholders in the project and ensure they express their requirements for the longer and shorter term. If you have all the key stakeholders who will be affected by a project in both the short and long term then you will be able get requirements, constraints and directives that provide the business rationale for architectural arguments.
Obviously, to get requirements from stakeholders you need to know who they are. If you already have a network of contacts then this will be easy. If you don’t then you will need to find some allies to help you identify key stakeholders.
With business requirements to back your arguments, you can give the program or project manager the “wiggle room” they need to start to change the project remit to take into account architectural concerns.
If you can’t get the business backing, then you have to accept the solution as is and move forward.
Step 5: Address objections
Sometimes there is push back that states “this is scope creep” or “this project is for XYZ business unit” or “we haven’t got time”.
Scope is best dealt with by specifically de-scoping requirements with knowledge of all requirements and an understanding of the implications of de-scoping. The de-scoped requirements allow others to take appropriate action with the knowledge of the project. It enables a roadmap to be developed to address de-scoped items. Refusing to collect requirements is not a reasonable approach.
Limiting stakeholder involvement based on who the sponsor is or which business unit has get the major benefits is also not reasonable or wise. Proper stakeholder analysis is essential and all affected stakeholders should be invited to contribute requirements.
Time is a legitimate concern but the reality is that only a small amount of time is required. Architectural decision making normally requires high level direction across a broad area and perhaps more detailed requirements for small but critical areas. Key people can be seen on their own at time to suit them. You don;t always need workshops, it is amazing what can be achieved in 15 minutes if you try!
Step 6: Drill down on the business impacts
The initial "gut instinct” about the solution that caused your concern should now be expressed as requirements that are at risk. They may be:
You will need to understand the benefits of achieving and the impact of not achieving these requirements.
Step 7: Frame your initial solution options
Your solution options should include:
There should be significant differences between the options. They may have different:
For each option a high level delivery plan with an initial assessment of business benefits and impacts with timing should be developed.
You now have the evidence to persuade key stakeholders that the program or project needs to take a step back and identify the best way forward.
Step 8: Carry out a feasibility study
All the previous steps typically have to be carried out rapidly and sometimes superficially because you may not have fully contained the momentum of the project or program.
If you have managed stakeholders and framed the options adequately then you should be in a position to investigate the identified options, identify the trade-offs, make a recommendation and develop the new solution architecture and roadmap.
Finally, Expect the unexpected
This will not go as planned. Despite logic, decisions you don’t understand will be made. You will never get the full story. You will never fully understand the stakeholders and their motivations.
If you don’t get what you want then accept defeat gracefully.
Be careful.