Want to cut to the chase and download a project cost estimation model you can use right away? You’ll find a link here.

truncate

Let’s start with a definition. An IT Cost Estimate is a point in time view of the resources and estimated costs associated with a project. This guide gives an overview of the process with focus on what you need to know from a Solution Architect viewpoint.

There are many elements to the cost of a project. Some obvious, others less so. For example, decommissioning is an element that can be often overlooked. Both from a financial viewpoint and planning for it within a design.

Cost estimation can be done using a range of techniques. From a spreadsheet created internally by a company or team to any one of a dozen established formal methods. Some sectors may insist on adoption of a particular type. That being the case this guide will be of less value. This summary will focus on the approach of using a spreadsheet and keeping things as simple as possible.

What is a cost estimate?​

A stupidly obvious sounding question. However, a recap will ensure we’re all clear. A cost estimate, summarises a complete view of the costs associated with an project. Complete meaning from inception to decommissioning. There are a lot of elements. Many of which may not be obvious.

Why does it exist?​

Mainly to aid with obtaining funding for a project. Some projects have drivers such as legislative change and will likely be done at whatever cost. Others will be measured against return on investment and compared with other candidate projects looking for funding.

They also help with resource planning but the focus is mainly financial.

Who uses it?​

- Sponsors - Call this group whatever you will. Ultimately there’s a group of, or better still a single person, responsible for the project. Whether it goes ahead or not. When and if it’s stopped.

- Programme Manager - Uses the contents to inform project sponsors of costs at various stages. It’s common for this role to have different titles.

- Project Manager - Alongside, or reporting to, the Programme Manager the Project Manager forms a team which is responsible for forming project costs. The Project Manager will work with other team members to a) identify resources required, b) collate estimates from those resources

- Solution Architect - Now we come to the most important input of the team. :) More seriously, the multidisciplinary nature of the role combined with a breadth of experience across technical and non technical areas means the Architect is well placed to understand a) who is involved, b) what they will do, c) for how long, d) unknowns of project delivery, e) risks etc.

There are others including Portfolio Managers looking after a range of projects within a department or division.

How is it done?​

It’s useful to remember a cost estimate is typically not a one time exercise. It is done at various stages of a project. Most obviously at the start but can be done at subsequent stages. Especially if future funds release is linked to existing estimates.

Generally the steps involve:

1. A project idea is formed. Some early analysis done around requirements and provisional solution ideas.
2. The requirements and solution inform the types of resource involved, technology implementation, risks and general level of comfort with knowns / unknowns.
3. The Solution Architect, with others, completes the estimation template
4. The estimate is peer reviewed, refined and agreed

Feedback loops​

Comparing the initial cost estimates of a project with the final costs provides useful insights that improve accuracy. Identifying areas of improvement and taking that learning into future estimates is the most efficient logical means of improvement.

A project team often disband after completion. What’s needed is the knowledge around cost estimation to transcend each project. Within some organisations that role is fulfilled by the Cost Estimation Team.

Cost estimation team​

Organisations that value cost estimation and do it well often have a dedicated team focused on this task. Typically a Cost Estimator will be assigned to your project. They will supply estimation models, help with completion of them and revisit estimates at various points of the project.

Involvement vs time​

Some resources have little to no involvement depending on the project stage. For example, testing resource doesn’t add value at the very beginning of a project. Yes, it’s useful to have early sight of things but in the case of testing resource when little to nothing is known about the solution not much can be added from the testing viewpoint.

Involvement from roles such as the Solution Architect decrease over time. The same goes for business analysts.

Estimates improve with time​

It’s common to do multiple estimates for a single project. Accuracy ‘should’ increase over time. In most cases it’s sensible to start with a high contingency built into cost. As much as 40%. After the discovery period more is known and it will be possible to revise the estimate. Now that could mean the costs go up or down BUT it’s common at this stage for there to be less unknowns so the contingency goes down. Say to 20%.

Key Takeaways​

References​

• UK Gov Cost Estimating Guidance - Focus on infrastructure more than technology but plenty of technology relevant principles.

Ensuring IT solutions meet organisational standards and strategies. In a nutshell, that’s it.

In this section we’ll cover:

• What is Design Governance?
• Why bother?
• Who is involved?
• How does it work?
• Solution Architect role?
• Solution Architect required skillset

What is design governance?​

Every moderate to large organisation will have a view on how their technology estate should operate. Design governance is the process by which proposed IT solutions are reviewed, approved and implemented. The tools, technologies and standards that provide the best blend of factors including cost and flexibility.

A Spanish Inquisition?​

Not at all. At least it shouldn’t be. The personalities involved play a big part in the ‘friendliness’ of such forums. As does the leadership and character shown by the session chair. Understand that people all have their own quirks.

Why?​

Managing complexity. It’s that simple. Large organisations have hugely complex, diverse technologies. Like all things in life, time changes everything. Approaches to solving problems change. Technologies and tools evolve. People come and go, along with their opinions to problem solving.

Using standardised technologies, tools and standards provides several benefits:

• Managing a standardised set of technologies, tools and standards is, all round, easier than a diverse one
• Cost savings from re-use
• Adherence to a divisional and organisational strategic view

Complexity is an unavoidable inevitably. The best we can do is put in place mechanisms to manage it.

Who’s involved?​

A small to medium organisation may have a single design authority. Large government entities or corporations are likely to have several. For example, different divisions of a large bank are likely to have a design authority aligned to each division.

Each design authority typically has a single representative from domains including security, infrastructure, information (data) and Enterprise Architecture. Each domain representative reviews the design and ensures it meets the standards relevant to their specific area.

A hierarchical structure of design authorities is common in large organisations. The structure of these can vary a great deal. A Solution Architect typically works within application design. Dedicated forums can exist for areas such as security.

Building a Rolls Royce or a Ford?​

The standards required in some areas of design can be overwhelming for many projects. Not every solution needs the same level of compliance. Sensible, frank conversations are required to ensure the most appropriate solution is implemented.

What good looks like varies between different people​

Design forum domain experts are custodians. They are held to account on ensuring designs meet the standards of their respective areas. What good looks like to them is meeting those standards to a high degree. Their accountability is measurable and long standing.

A project and the team delivering a solution (and its design) is a transitory thing. They provide a solution to a problem and often disband. What good looks like to the project is delivering on time, budget and with minimum risk.

Understanding this concept is essential. It enables a Solution Architect to identify points of potential contention early and initiate the appropriate work to reach an informed compromise.

How does it work?​

First and foremost, the design forum is not the place for design work and debate. It is the place where experts from various domains come together to discuss as a group something they should already understand.

1. Organisation defines its high, mid/low level standards and best practices
2. Solution Architects produce a design that meets those standards
3. A review slot with the design forum is booked and a copy of the design is shared with reviewers
4. Reviewers meet to discuss the design and approve or decline the proposed solution

Role of the Solution Architect in a design forum​

1. Ensure the requirement is clear and measurable
2. Understand the constraints and dependencies that the solution must take account of
3. Familiarise yourself with the standards, policies and protocols of your governance area
4. Document the most pragmatic, clear and concise solution possible

Design Authority Skills Required​

• Pragmatism - More often than not a solution design will be a compromise. Time, cost, technical constraints are all factors that influence any proposed solution.
• Communication - You’ll need to convey your proposal in a concise, clear and effective way
• Confidence - If you’ve done your prep, spoke to people ahead of time, you should know the outcome. I say know the outcome rather than ‘get approval’ because there are times when you know approval won’t happen but there are reasons for attending. Another story…

Key Takeaways​

Related topics​

• High level solution design - TODO

Want to cut to the chase and download a project cost estimation model you can use right away? You’ll find a link here.

One of the most common activities for a Solution Architect is production of a design document. Most organisations have their own template and there’s more commonality than not between them. In this article we’ll go beyond what is useless coverage of the content headings and focus on tips and techniques for completing these documents efficiently.

truncate

What is a Solution Design?​

No, I’m not being sarcastic! It sounds so basic but as I often do let’s ensure we’re all clear from the beginning. My definition of a Solution Design is:
A blueprint which defines how a software system will be implemented. It describes the components, connections, data, security and related elements which provide a high level view of how a technology solution will be implemented.

Now that we’ve covered what may appear to be an obvious point we can focus the rest of this piece on practical tips and strategies for completion. I say this as simply taking the headings of a Solution Design document and discussing them ad-nauseam offers little value.

Who’s interested in its contents?​

Let’s work backwards from who wants what out of this document. That’ll start to inform the task list of things we need to get done.

Who	Interest
Project Manager	Governance gateway to progress (financial, technical)
Technical Design Authority	Governance approval from various domains. Security, data, infrastructure, Enterprise Architecture etc. Does it meet standards?
Analyst	Requirements alignment
System owners	Approval of changes proposed to individual systems
DevOps	Can the proposed changes be successfully coded / implemented?

Who validates it meets requirements?​

Often nobody! As I put it, the Solution Design could often be a recipe for cookie dough. Enterprise Architecture check for strategic alignment. Are you using common shared services and building things that align with the ‘vision’? Domain experts in data, security and infrastructure check their bits with much the same purpose. I’ve listed a Business Analyst as someone with an interest in the design. So don’t they have the role of checking it meets requirements? In reality, no. They’re often included in the design but I can tell you from experience this generally doesn’t happen. What, now appears an old school method, used to happen is we would have a requirements traceability section / sessions. Objective being, to show physically in the design how a requirement is met. It was a part of the governance process. However for at least the past 10 years that’s not been the case. The key point here is highlighting a real world observation which is I see this as a real gap that’s very common. So don’t be surprised if you find yourself going through a bit of a box ticking exercise. Something that has a veneer of robustness to it, and indeed does from some viewpoints, except the main one that matters. Does it provide a solution to the actual problem it set out to solve?

---

Design checklist​

At the start of most engagements you need to find out what, who and when as regards your obligations. You will be accountable for design approval. You’ll also be responsible for most, if not all, of the design’s production. It used to be that domain specialists such as infrastructure would be responsible for ‘their bit’ of the design. That’s far less common these days. A very clear divide becomes clear as I write this. Producing the design is one thing. Getting it through a Technical Design Authority is another. This topic is focused on the design document itself. I’ll cover the TDA separately but you’ll definitely see overlap.

1. Governance - Identify what’s expected of you, how it works, who the signatories are. Usually you’ll have an Intranet or similar guide showing everything the Technical Design Authority wants, when and how.
2. Engage people early - Can’t stress this enough. Get some early thoughts together on a solution, find the people who will sign off your design and go speak to them. Start with a 15 minute intro on who you are, what you’re trying to achieve and how you think you’ll do it. Nothing formal. Be economical with time and precise with your thinking.
3. Put everything you know into the design from day 1 - A key measurable objective of your work is the design. Work back from there. Put all your thinking into the document. Flesh out ideas. Iterate. Don’t make the mistake of having material everywhere and think I’ll get around to putting it into the design later. You’ll f**** it up! Be that underestimating the time needed, duplicate effort, miss key parts etc.
4. Diarise time with signatories and third parties where necessary - Get slots in the diary to review relevant sections with people. e.g. Validate your designs with them. Be blunt and ask the question of are you happy with this.

Design Example​

You can download a copy of my design template here. There’s little value in going through it section by section in this guide. You’ll find comments within the document providing guidance on each area. There are definitely tips and techniques you can use to ensure you efficiently complete each section. The document itself will cover that. What I’ll say is once you’ve seen literally dozens of these you’ll find they are all much the same.

Key Takeaways​

Related topics​

• Design Governance - TODO