2 posts tagged with "templates"

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.

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