Try This: Everyone Draw The Architecture – A Retrospective

There’s this really cool idea I read about in Luke Hohmann’s book “Beyond Software Architecture : Creating and Sustaining Winning Solutions”, only I haven’t yet found an opportunity to use it… until a couple of nights ago.

Have you ever been in a situation where: you’ve started working with an existing team and realised that things aren’t quite right?  The way people talk about the solution isn’t entirely consistent, things seem to be going in random directions, maybe they are talking at cross-purposes or even arguing about how things are done?  You might be familiar with this – it’s the kind of discussions you get when there isn’t a consistent team view of what the architecture is.

Luke’s idea is pretty simple:

  1. Get everyone in the team, as an individual (no talking), to draw the architecture as they perceive it.
  2. Once everyone is done, put all the drawings up on the wall and review as a group.

Have a discussion along the lines of “what occurs to you and the team”, and “do you find congruence? If not, why not?”.

The idea fascinates me, but I hadn’t yet had a chance to do it – until I got a chance to speak at the Product Tank Wellington meet-up.  This specific meet-up was basically about architecture, and the intersection with product development.  I wanted to introduce some architecture ideas and get some discussion going around how they perceived architecture in their space.

Here’s the intro slides and brief I gave for the exercise:

Try This Draw The Architecture

Try This Draw The Architecture - brief

It all sounds great, what could go wrong?

Well, I was feeling a little bit flat that day – nothing major but not quite as “on to it” as you’d want to be if you’re presenting – especially when some of the audience are possibly more qualified in some ways to present on this than I am.  During the exercise I walked the floor observing, and after a few minutes we put all the 16 or so pictures up in the wall.

Everyone gathers around, a piece of pizza in-hand, and waits for the pay-off moment where I take what they have done and deliver some revelation and insight.


Unfortunately it was bit of a “fake it until you make it” moment.  Because I hadn’t done the exercise before I was a little unprepared for what to do next, but that’s the problem with activities like this where you need the input from a group of people – it’s a little tricky to test it out in a meaningful way.

Before I explain further – take a look at some of the diagrams – what might you have said?  (Think of that as a little self-test).

30-08-2017+7-35+PM+Office+Lens_30-08-2017+7-36+PM+Office+Lens 1_30-08-2017+7-36+PM+Office+Lens_30-08-2017+7-37+PM+Office+Lens 1_30-08-2017+7-37+PM+Office+Lens 2_30-08-2017+7-37+PM+Office+Lens_

I managed to waffle a little bit so it wasn’t a complete farce, I asked a few questions and we generated some “ok” discussion – so I don’t think it was a totally wasted effort, before moving the conversation on.

Retro – What Did I Learn?

So first off – my thanks to everyone at the meet-up who took part, thanks for being guinea pigs in this little experiment!  I hope you got something out of it even if it wasn’t necessarily what I was aiming for.

What Worked Well:

One of my colleagues at Middleware attended, and like a lot of people I meet he’s interested in architecture but the whole concept is a little intimidating and he’s keen to know more.  He said the exercise was really great for keeping people engaged:

  1. It gave people a chance to get up and stretch their legs, good for energy.
  2. It gave people a break from listening to me and watching slides.

But that’s not exactly a surprise, in my experience (both presenting and being presented to, anything interactive is usually positive).


  1. The volume of information to process.
  2. The variety of visual styles and approaches.
  3. Messy handwriting.
  4. Having very little time to analyse and respond – in front of a group.

I tried to look for common themes and areas where people had varied wildly; and in this regard the exercise went exactly as I had anticipated as there was a lot of variety.  The problem was that:

  • The insights that occurred to me weren’t quite in-line with the brief I thought had given the group, and I didn’t want to start making comments people thought were unfair because the goal-posts had changed.
  • I had a clear idea in my mind of how the exercise would go and how I would respond, but my assumptions didn’t entirely survive what actually happened, and consequently I felt I didn’t responded as well as I wanted to.

What Could Have Gone Better If:

  1. I had been more “on to it”.
  2. I had done more preparation and thinking about what might get drawn, and how I might need to respond.
  3. I had thought to ask one or two people to give us a quick summary of what they were thinking and the process they went through, as a way of generating some further discussion.
  4. I had picked a drawing at random and tried to interpret it “Ok, this is what I think you’re saying”, and use that as a way of generating some discussion and insight.  Repeat as appropriate.

Final Observations

The context of the exercise is important, as the objectives flow from the set-up:

  1. In this exercise people were dealing with a domain problem (flight bookings) that was essentially new to them – I presume they all have some background idea of such a system, but it not like they will have be actively building one for some time – which would be the case in a real-life scenario.
  2. It’s similar for the reviewer/facilitator; they way I would run the second half of the exercise would be different because what I needed to get out of it would have been very different.  Unlike an exercise at a meet-up, in a real-life project I would be bound to the outcomes as a member of the team – i.e. I’d have to live with them, so the drivers would be immensely stronger.

Would I do it again?

Absolutely.  In some ways the exercise was bit of a failure, at least in the short term, and I can only hope that people were able to take away something useful from it.  That said, it was a success from an iterative point of view: I now know a lot more about this technique and how to make it better next time.  These learnings will also help me should I ever need to do it “for real” in a project.

I also hope it was successful in that this write-up gives you something to think about, and perhaps the inspiration or basis to run this exercise yourself – either informally as a meet-up/learning activity, or as a “serious-face” exercise as part of your project.


I’d like to belatedly comment on the work people did and share some observations on the content and possible thought-process (rather than the visual style):

  1. It’s interesting how people’s background comes through – the second diagram takes a decidedly infrastructure based lens.  This is not necessarily bad.  In situations like this (where it might not necessarily answer the question you thought you had asked) it may prompt valuable questions you hadn’t thought to ask.  That’s a strength of this sort of exercise, the variety of responses can provide insights you hadn’t expected and therefore might not have uncovered.
  2. It’s also interesting the different functional emphasis people use.  For example the last one seems to have a finance focus – three of the most prominent boxes are “Prices”, “Finance” and “Payment”, the first two of these are also in the center of the diagram, which might also be where they started drawing – and where they conceptually started.
  3. The first one is interesting because it blends functional concepts like “flights” and “Finance” with solution/technology concepts such as the enterprise service bus that links stuff together.
  4. The third example appears to have started with the “portal”, large and across the top; it then decomposes the portal down into parts, and then further elaborates those into related concepts.  It’s easy to see how the drawers mind may have been methodically working through the problem.
  5. The second-to-last example is interesting because it seems to very much be an exploratory diagram, where the drawer is literally working it out as they go: drawing some concept and then digesting that before adding the next piece.  There’s absolutely nothing wrong with this approach.  It’s true that a “messy” diagram might reflect the drawers understanding of the domain, but it hasn’t stopped them bringing in elements that others missed, such as thinking about search through to external providers (Expedia).  Like some of the other, this example also mixes technical and non-technical concepts (think “apples & pears”): “bank API’s” and “Weight Allowance”.
  6. Not all of the examples have included people/actors.  Neither approach is wrong, but to me including people starts to provoke thoughts around who does what, what scenarios they might have, and begins to bring people back into the discussion – which I think has a lot of value.

Were you one of the participants in this exercise?  If so, please feel free to add your thoughts in a comment.




Design Thinking Entrée, with Blair Loveday, et al (#ITEA 2017)

Coming out of the ITEA conference, I referred to three magical signs that (IT) architecture is going through a positive transformation; #3 was around design thinking, a topic that a number of speakers covered in varying depth.  Amongst those was the heretic Blair Loveday; I mean sheesh, the guy’s a BA Chief Culture Officer, what blasphemy is this, him presenting at an architect conference?

Blair and the others spoke enough about design thinking to wet our appetites, but not nearly enough to constitute a meal; so, based on what I got from the conference and after some digging of my own, here’s my quick overview of design thinking – a sort of entrée to get you started.

In a Nutshell

I’m conscious that I’m partially trying to appeal to IT architects, let me do so by using the term ‘scientific method’, because it’s going to get a bit touchy-feely later on.

According to wikipedia, Design Thinking is comparable to the scientific method (feedback is obtained by collecting observational evidence and measurable facts) but with the addition of also considering the human aspect, or emotional state.  The inclusion of the human dimension is a key theme that you’ll find throughout design thinking literature.  For example, use of empathy is one of the specific techniques suggested for during the ‘learn from people’ phase.

The Three Lenses

One of the concepts Blair used to describe design thinking was a “the three “lenses” that you’ll see repeated in design thinking literature: desirability, feasibility and viability.


Blair respectively described these people, business and technology lenses, and then talked about then in the context of innovation – by type, depending on which lenses overlapped.  The central overlap of all three was “Experience Innovation”, which sounds fine but with all due respect is just a smidge too touchy-feely, even for me, on Monday – but that doesn’t matter.

Design thinking, according to Blair, is centered on the people / desirability lense – which is in keeping with Wikipedia’s view vis-à-vis the scientific method.  You’ll notice that this puts emphasis on emotional and functional innovation.

The thing I really like about this model is that it’s simple yet useful, calls out the human part (which is pretty essential) and provides one of several good anchors to understanding design thinking: making stuff that “is cool” or “just works”, for people.

Getting to Grips: Four Into One

Trying to understand design thinking by reading about it online is a little like talking to people who witnessed a traffic collision: everyone’s got a slightly different view.  Given how long design thinking has been around that’s probably not surprising.  I found a number of approaches.  What I’ve done below is to try and distil the main phases from the 4 interpretations that I studied:


The colour groupings are my own, looking for commonality across the different approaches, and are only indicative.  The four approaches are based on (from top to bottom): Design thinking example video (wikipedia), IDEO, Stanford University’s ‘Taking design thinking to schools initiative’ (wikipedia), and ‘A Framework for Design Thinking’ (Creativity at work).  Links to these references are below.

The third process, from Stanford, is the one Nick Malik referred to in his talk at ITEA 2017.

Chris Tuohy’s talk on experience’s at Westpac also touched on design thinking.  The Westpac approach has seven phases (not including an 8th step which seems to be a decision point at which the prototyped ideas are passed into a delivery-focused design and build lifecycle.  Unsurprisingly, these seven phases are all in common with those suggested by the 4 approaches above.


Distilled Comprehension: One from Four

Here’s my general take on what things a reasonable design thinking process should include:


  1. Learn from people: 
    1. IDEO seem to refer to this as “Insights”, observation, learning from extremes, interviews, immersion and empathy, and doing this all through the three lenses.
    2. Getting an idea of people’s motivations, habits and delights is a good place to start.
    3. A concept I came across more than once was the idea that people on the extremes (think bell curve) are good at helping to explain ideas that the mainstream are less able to articulate.
  2. Find patterns:
    1. Look at what you’re learned, try and make sense of it.
    2. Look for themes, apply intuition.
    3. Put yourself in the shoes of the users, leverage empathy.
    4. Distil design principles.  For example ask the “how might we” question: if a design principle or theme says “x” ask how you might turn that into a specific idea or prototype (and remember the three lenses).
  3. Generate ideas: 
    1. Don’t prequalify ideas out, just generate them.
    2. As IDEO say, “Push past the obvious”.
    3. The emphasis is on creativity.  Basically this is the divergent thinking (creating choices) phase.
  4. Make tangible, prototype and test: 
    1. This is the complementary convergent thinking phase (making choices).
    2. Make things tangible and real through prototyping.  Use any method you like, but make sure it’s using something that will resonate with your audience.
    3. Refine and improve.

Some of the descriptions include steps that come after what I would consider to be the core of design thinking (e.g. delivery).  I don’t think that’s necessarily bad.

You could say these were “steps”, implying a formal process; obviously you want to take time to understand before you race off and prototype stuff, but to put constraints that are too formal on the approach would do it a disservice.  For example, the phase of generating ideas and prototyping them could (and even should) be an iterative process.  After all: how many iterations = how long is a piece of string.

Finally, I got hold of Peter G. Rowe’s book “Design Thinking” from the Wellington public library; I haven’t made serious in-roads yet, but it looks interesting.  One of the things about it I am keen to explore the author’s views it given he’s coming from the perspective of a “real” architect (i.e. buildings, not IT).

Further online reading and viewing:

  • Wikipedia – check out the example video, it’s a really nice little summary.
  • IDEO – some useful content for sure, but not a lot of it (unless I did a “man-look”).
  • Creativity at Work

Are traditional architecture engagement models still relevant?

An article I wrote, originally posted on the Davanti Consulting website, 30th November 2016, reposted here with permission.

Reinvention dominates the business landscape, pervading how we work and how we engage with those around us. As an architect, I sometimes wonder how many of my industry colleagues have noticed this and contemplated similar innovation. As architects we are often perceived as dinosaurs; surely then, the time to start reintegrating ourselves is now.


A good architect can bring excellent value, but that value is lost if it arrives too late. Some of the barriers to this value even appear to be systemic or stem from entrenched legacy thinking.

The way in which architects engage is influenced by several factors, including:

  • Control: architectural governance is often perceived as regulatory rather than wisdom.
  • Processes: these are often complex, “heavy”, unwieldy and time-consuming.
  • Resourcing: architectural capability is often scarce, a scarcity which is exacerbated by heavy processes.

Traditional architectural engagement tends to be based on a “these are the rules” approach renown for volumes of documentation and thinking before any real work starts. Interestingly this way of working doesn’t really have a name – it “just is”. There’s definitely a number of architects who got the Agile memo, but overall that percentage is still relatively small.

There are architecture frameworks such as TOGAF, but a framework is not an engagement model. TOGAF has the “Request for Architecture Work” concept, but this is more of a one-shot form. TOGAF is aimed at enterprise architecture and whilst it refers to solution architecture it does not attempt to address how architects should engage with stakeholders in a product or project delivery setting.

At the project level, architectural engagement will ideally be in the form of an embedded solution architect. Ideally their engagement will start with the business case and continue through to overseeing the implementation. At worst, their involvement will be sporadic or non-existent. For various reasons such as a scarcity of architects, coupled with the weightiness of architecture processes, this engagement will likely be forgone for smaller projects. The associated risk is that smaller projects often grow into bigger ones, consequently attracting belated architectural attention.

So, short of everyone drinking the agile Kool-Aid what should we do? What might a revamped engagement model look like? How do we start, and what are the challenges we need to solve?


The goal is to ensure that architects are able to add value in a timely and sustainable manner.

As architects often work as part of an architectural practice, and within the boundaries of architectural governance, both the architecture practice and governance may need to be revamped:

  • The architecture practice should reinforce behaviours and processes that make the team more consistent in their approach, allows them to support each other, and thus positions the team to offer a more consistent experience to their business clients.
  • Ideally architectural governance should support the team in this change as they are its ambassadors. Governance should not be about doing architecture for the benefit of the architect.

At a high level, think about making these changes so that the following value is unlocked:

Do this 

 So that

Revamp governance.
  • It provides supportive guidance, rather than be a place where things go to be vetoed.
  • It is easy and relatively painless to use, and therefore gets used more often.
Create a toolbox of processes, tools & artefacts that is accessible.
  • Non-architects find it easier to understand and use, as a result the architects will need to spend explaining it.
  • More time can be devoted unlocking value and less time given to discussing the process.
  • Architects have the time (and opportunity) to spend engaging more broadly and more regularly with the business.
Encourage architectural mentoring and coaching.
  •  Architects can be seen more as collaborators and supporters.



This isn’t a wholesale re-write, but more of a health check and possible diet.  You might be familiar with the concept of a good value proposition being one that your grandmother could understand; check your architectural governance processes and make sure they can pass that test. Make sure that what is expected is very clear, not onerous, and that its business value is self-evident.


Empowering the business, whilst keeping them and the architect team aligned, is going to mean having some supporting materials available. These will work with the revamped governance and be very practical in nature. In situations where architects are working with the business in a mentoring context they will need materials that they can refer the business too, and which the business can use with a degree of self-reliance. These materials should outline:

  • Technology constraints that are deemed important, and why. If possible, a sense of direction, as business and architecture are seldom static.
  • What questions to ask themselves, and when, so that the business doesn’t paint themselves into a corner.
  • Areas of danger or concern; things they should escalate to the architect so that they can be appropriately supported. Thinking along the lines of RACI can be helpful – for example: when should they inform and when should they consult.

These material might be pre-written guides, checklists and (lightweight) documentation and diagrams, or, checklists that the business progressively complete with varying degrees of assistance from an architect. They might be anything from risk assessments, solution option assessments to solution architecture definitions.

Creating materials that effectively support the business (and the architects) means creating materials that are easy to access – not just in terms of being easily located, but also easy to read, and understand.Materials should be suitably light-weight, so that they are easy to consume and keep up to date. After all there’s no point freeing up an architect’s time just to write more documents.

In terms of the artefacts you expect the business/projects to deliver, ask yourself “who will read the documents”? If the answer is “only other architects” then exactly what value does it provide and is it really necessary?


There will always be a need for architects to do the architecture, and to be deeply embedded in a given project; but conversely there are many opportunities where a lighter touch may be equally effective.

Coming to the business with a mentoring approach places everyone on a more equal footing, and increases the chance of a more meaningful collaboration. The architects are close enough to spot potential issues, establish some sort of rapport with the business and lead them where appropriate. The business is free to do some of the heavy lifting themselves, freeing up some of the architect’s time.

If successful, architectural value should become easier to unlock, and more valued by everyone.


So far we’ve focused on the engagement model, i.e. elements of structure, broad approach and the rationale behind it. Hand-in-glove with those concepts is the style of engagement, i.e. the communication style used and how you relate to stakeholders on a personal level.

It is vital that you tune-in to your audience. Architects need to be leaders, they need to manage stakeholders of all types, and in a range of different situations. To do this effectively will require you to adjust your engagement style to suit both the audience and the message.

The best laid plans are easily ruined by poor execution, and as good architecture is dependent on good communication it is essential to get this right.  Effective communication is a substantive topic in its own right, and beyond the scope of this article, but to get started, consider:

  • Being available, approachable and responsive.
  • Being good at active listening.
  • Being able to relate to others.
  • Being able to simplify the complex.
  • Being able to speak up.
  • Being good at asking questions.
  • Being effective at persuasion, mediation, facilitation.
  • How to say no without coming across as (or actually being) a roadblock.
  • Picking the right communication style for the audience.


As a discipline architecture offers great value, and architects tend to be clever people, but realising that value is not straightforward – as architects we need to be proactive, we need to be mindful of changing expectations as the world changes around us. Just because architecture deals in the fundamental does not mean it is impervious to change.

As practitioners of architecture, take what you can from new ways of working, such as Agile and collaborative tools.

Show the business and the rest of IT that architecture is not something up an ivory tower, and that we can lead innovation and change by example.

Software Estimation: How To Do a Rough Order of Magnitude

Here’s the best software estimation technique I know; it’s not as good as doing proper Planning Poker and then measuring your actual velocity, but it’s a pragmatic approach if you are forced to come up with a time-based estimate for political reasons or to support sales activity.

I suspect other people use this process or one just like it – no idea what they call it, but I tend to refer to it as a “Rough Order of Magnitude” or ROM.

At first glance it looks pretty straight forward and semi-obvious, but, like many things in life the detail is where the important stuff is.  So lets start with the main steps then get into the detail:

  1. Design the system:
    • On a whiteboard / paper.
    • Decomposed down to a reasonable level of detail.
    • Make a note of all related tasks (e.g. environment set-up), plus any assumptions and constraints.
  2. Do two estimates:
    • For each and every part of the design: “best guess” & “worst case”.
    • Include all the related tasks.
  3. Write-up.

Design the System

The objective here is to come up with a design that should work, and then identify each and everything you need to do to build it.  Effectively you’re aiming to design down to the module/component/widget level.

For example, if you’re building a webpage that searches a database this implies that your design will include:

  • A database.
  • Tables in the database (do know what the schema is likely to be?).
  • The tables will have to be query-able (so will you write Stored Procedures?).
  • And so on.

Here’s some real-world examples of the kind of thing you’re after:

As you go through the process of coming up with the design you’ll be making assumptions, working within constraints and coming up with questions that influence the estimate – make sure you note these down.

Other tasks – things that aren’t part of the solution but will be part of the work/effort in delivering the solution; make sure you note these down as well.  For example:

  • Setting up development environments, source control, etc.
  • Setting up development servers, databases, access to them (permissions), and so on.


Once you have the design you need to go through each module/component/widget and every task, and for each of them you want to come up with two estimates:

  • Best Guess – the shortest amount of time it could possibly take.
  • Worst case – the longest amount of time it could possibly take.

For example, let’s assume you needed to deploy part of the solution to Azure (or AWS) – but you have never done this before:

  • Your “best guess” might be half a day:
    • Because it’s only uploading  a package, how hard can it be.
  • Your “worst case” might be 3 days:
    •  Half a day just to login because the details you get given will be wrong / the account will be the wrong type / you won’t have the level of access people said you’d have, etc.
    • A day to do get hold of a test package that you can actually upload, plus all the research and reading you’ll need to do to figure out what it is you actually need to do, maybe even some time to do some quick prototyping.
    • Half a day to refactor your configuration options and redo your build so that it will now work based on what you just learnt.
    • A day to actually upload it and then figure out how to verify you’ve done it successfully.

As you might have figured out, the best guess estimates are where you can be an optimist, you can assume all your assumptions are correct, you’ve successfully mind-read the clients intent, there will be minimum defects, you’ll have no security / permissions issues connecting to the server the first time, and so on.

With the worst case estimates you do the opposite: feel free to take a hard line on stuff, assume your assumptions are wrong, that the data will be far more complex than you hoped, that the test data you get will be of really poor quality, and so on.

The key thing is to keep the estimated grounded in some rationale, that’s based on your experience and can be justified.

If you’re working on a whiteboard, just put your estimates straight onto the design (use a different colour).

Use any unit of time you like that makes sense (hours, days).

The significance of two estimates

This is one of the more subtle but powerful aspects to providing two estimates: the bigger the difference between the best & worst cases, the more pronounced the risk profile. This can apply to the overall ROM but it’s especially interesting at the task/component level. Consider:

  • You’d expect relatively larger items to have relatively bigger estimates – and a relatively larger best/worst range.  You might not think this means a greater level of risk, but remember that Planning Poker specifically uses a number scale that rapidly increases in size; the reason for this is that larger items are inherently harder to accurately estimate.  To me, this means they automatically attract a higher level of risk.
  • Ignoring the sheer relative size of an item, a bigger best/worst estimate probably suggests you’re less sure about the nature of the item, that it has more assumptions and unknowns.  All reasons to consider it to be a greater risk.

Once you’ve finished the initial estimation of all items and tasks, review those that have abnormally large best/worst estimates.  can you break them down into smaller pieces?  If not, discuss them and note down any risks and assumptions you identify, and include these in the write-up.

As a team or individual

I have taken this approach on my own, but usually it’s as part of a small team – e.g. if I’m the solution architect on the project and we get given a new major feature to estimate.  I’ll take a few of the key developers into a room to thrash it out.

As per Planning Poker, estimating as a group is always better, specifically:

  1. Estimates arrived at by consensus are usually more accurate.
  2. Others will spot stuff you missed, and a fresh pair of eyes is always good.
  3. It’s way more fun.

Going further, use the other tenets behind Planning Poker:

  • Avoid cognitive bias / anchoring – i.e. when discussing the system, especially when you get close to estimation.
  • Let everyone think of their estimate before people start revealing their own.  Because you’ll be estimating using actual hours or days you can’t really use a card-deck, so you’ll probably just have to rely on people being honest and not privately changing their estimates when they hear someone else’s.  Adjust your level of ceremony as you see fit.


At some point you’ll need to provide the estimates to someone.  What I tend to do is take photo’s of the whiteboard (to capture the design).  The assumptions, questions and so on I’ll usually jot down straight into OneNote so they are already digitized – that way I can just dump them into my write-up.  Usually the write-up will be semi-informal, possibly just an email.  You don’t have to waste time with unnecessary formality and ceremony – but the write-up should:

  • Be very clear.  Senior stakeholders / non-techs should at least be able to follow the narrative and understand the bottom line.
  • Come across as a professional piece of work, so that people won’t start questioning it’s validity based on how it is presented.

Remind people that the ROM is not a schedule, it has no sense of inter-dependencies or elapsed time, it is merely a sense of how big the work is and what the solution might look like.

Take particular care to explain and emphasize that you are providing a range not a quote. Overly zealous sales people and project managers will be tempted to take the smaller estimate and only provide this to the client.  Make sure they understand this is ill-advised. If you are hard pressed say: “the guy who wrote the article said that in his 16+ years involved in software development, every time someone took only the lower estimate things ended badly”.  If you’re from that British school of understatement, spoken with a touch of Jeeves-to-Wooster, you can say that the results will be “sub-optimal”.

You may also choose to throw all the items into a spreadsheet, with the two estimates, so that you can easily tally them up, include them in estimates back to the client, and so on.

Pros & Cons

The estimates are only as good as the experience and professional judgement of the people involved; the estimates are effectively based on nothing more than peoples prior experience, so ensure that those doing the ROM know what they are doing.  Involving juniors is good – it’s a great learning opportunity for them, but ensure they aren’t being left to fend for themselves.

As an estimation technique, it’s fairly fast and light-weight (but with a degree of rigor) so it’s useful in fluid situations.