Project Management

Is ‘The App That Chimes The Loudest’ Robbing Your Attention?

One of the first jobs I had was in an insurance broker’s office.  This was back in the day when (believe it or not) people used to buy home and motor insurance face-to-face or over the phone from a local broker.  I sat in front of a monochrome ‘green-screen’ monitor in an office full of folders, secure filing cabinets and a lot of physical paperwork.  Many of the “information systems” we used were entirely manual, including a ‘date file’ that was nothing more complex than an expanding folder with 31 pockets.  If you wanted to remind yourself to review a particular item on the 28th, you’d put it in the pocket marked ‘28’…

Image Credit: © stokkete — stock.adobe.com #297320833

A lot of my work was administrative and customer facing.  It was a small office, and work was triggered by information or requests arriving. When I started work, we didn’t have e-mail, so the primary ways that information got in or out of the office were by:

  • Post (delivered daily, batched and sent daily)
  • Fax
  • Phone call
  • Face-to-face
  • Occasional courier/urgent document delivery

Since many of the processes were manual, work was very tangible and visible.  Motor policies were applied for via a ‘Proposal Form’, at which point a handwritten ‘Cover Note’ was written. The proposal form was then sent to the insurance company by post. They then sent a ‘Certificate’ back a few days later.  I am aware of how frighteningly archaic this all sounds, but it really wasn’t that long ago…

This tangibility somehow meant that there was an inherent hierarchy of attention.  Let’s imagine it was first thing in the morning and I’ve sorted the post and I’m working through it (based on the urgency of the items).  The phone rings, I’ll pick that up because it requires an urgent response, it’s synchronous and somebody is there waiting for attention.  If somebody walks in, I certainly won’t hang up the phone, but I’d gesture to the person to take a seat so they know I’ll be with them as soon as I can.  If a fax came, or if a second bundle of mail arrived whilst I was on the phone or speaking face-to-face with someone, so what? It’s asynchronous, it can (probably) wait.  I certainly wouldn’t let a newly-arrived fax or letter interrupt a face-to-face conversation with a customer (unless there was a very, very good reason to do so).

Technology and Intangibility Disrupts the Perceived Hierarchy

Project Lessons from Aviation (Part 4): Aviate, Navigate, Communicate

Cockpit of airplane

Image Credit © bennymarty, Fotolia.com #93453181

In aviation, I gather, the mantra ‘Aviate, Navigate, Communicate’ has been a staple for pilots for many years.    I first heard this expression a few years ago, speaking to a fellow BA at a conference who also happened to hold a private pilots licence.  According to the FAA website, the mantra provides a useful aid-memoir for the pilot-in-command, particularly in emergency situations:

 

Aviate: Keep the aircraft in the sky, and keep it under control

Navigate: Monitor location, and navigate to the intended location

Communicate:  Speak to others (presumably this would include those outside the cockpit, e.g. air traffic control and also the passengers on board).

 

When I first heard this mantra, I was struck by its succinctness but also its usefulness—it is a concise shortcut that helps prioritise activities, especially when time is short and when the pressure is on.  It also struck me that it is an interesting model through which we could consider a project.  But perhaps, for a business and project environment it might need some adaptation…

 

Communicate, Communicate, Communicate?

The Role of Emotions on Projects

When carrying out Business Analysis, it is very tempting (and often considered advantageous) to highlight our objectivity.  As professionals looking ‘in’ on a business situation we are, it is said, able to see the ‘wood from the trees’ and work with our stakeholders to co-create solutions that they may not have found on their own.  Indeed, this is one of the major benefits of business analysis—we bring a fresh perspective, challenge and a range of techniques that help ensure our organisations meet the outcomes that they are desiring. Yet, whilst appropriate detachment and separation is useful, I am beginning to wonder if objectivity has its limits. 

 

Stressed businessperson with broken mechanism head screams

Image Credit © alphaspirit – Fotolia.com #97226946

We talk a lot in the analysis community about stakeholders—how to identify them, how to engage them and how to understand their perspectives. We might even talk about how to ‘bring people on the journey’, and how to understand the reactions that people have to change.  You are probably familiar with at least one theoretical model that charts the typical emotional responses to change (e.g. ‘SARAH’).  Yet in talking this way, are we assuming that as practitioners we have no emotions? That, like Spock in Star Trek we somehow experience no sense of fear, excitement, joy or regret?

 

I am sure we are not trying to imply that at all, but I wonder whether it is useful for us to consider our own emotional ‘state’ more.  After all if we are going to engage with a situation, with the stakeholders, doesn’t that involve being engaging?  And whilst there are of course techniques that can help with this, if we ignore our own emotional state then we are going to likely find ourselves giving out incongruous messages.  Like the customer service agent who says “uhh, yeah, probably”, we risk sounding seem half-committed—and as crucial practitioners who lead-from-the-middle it is so important that we ‘walk the talk’.

 

A Different Perspective: “Change Changes the Changer Too”

The Illusion of Progress: Half a Job Is No Job

Cartoon of business analyst spinning plates, with a manager coming with more plates (metaphor)Working on projects can be challenging at times. It can feel like we are spinning a number of plates, desperately trying to keep them from falling to the ground. Add in human factors, power and politics and it is more like spinning plates in a storm (in the dark), with different stakeholders having different views over which plate is most important. This dynamic is one of the things that makes the role so interesting and varied.

 

In this challenging landscape, part of our time is spent planning and monitoring the analysis work. If you are a Principal or Lead BA this may involve leading and managing the work of others, else it may involve planning and structuring the crucial day-to-day work that we do individually. It is easy to overlook this part of the job as it is something we probably do without thinking, yet it is a crucial enabler for the efficiency and effectiveness of our work. When things get busy, it can become tempting to stop planning and monitoring—there may be a pressure to “just get going”. There can be an unstated pressure for us to spin our plates without considering how many we are tending to (and how long we’ll be spinning them).

 

This can lead to a significant danger. Without an appropriate plan, we can get caught in a never-ending loop. It is easy to end up over-committed, as it is so temptingly easy to take on just another ‘small task’. But each task takes time, and before long we find ourselves flip-flopping between activities with an uncomfortable sense that things aren’t quite under control. The more tasks we take on, the more this insidiously uncomfortable feeling grows—we’re worried that we’re going to drop a plate without even knowing it! Perhaps you recognise this feeling?  I know I do!

 

The Illusion of Progress

Benefits Realisation Shouldn’t Be A Witch-Hunt!

  • Adrian Reed 
  • 6 min read

Unhappy/angry office worker with head on deskOrganisations that initiate projects generally do so to embed some kind of favourable change into their operation. The types of outcome and benefits desired will vary depending on the organisation’s situation and strategy, but might involve increasing revenue, reducing costs, achieving regulatory compliance, improving customer service or any other combination of goals. Let’s imagine that a financial services organisation decides to streamline its ‘customer sign-up/on-boarding’ process. Possible benefits might include providing enhanced customer service (leading to an increase in sales) and lower processing costs (leading to higher profits). There are likely to be many different ways of achieving these outcomes—and those options are likely to be examined in some form of business case. For small projects this might be a very lightweight document, with larger projects and programmes needing a more thorough and formal document. Either way, the relative pros/cons of various approaches will be considered—including the tangible and intangible costs/benefits, and also the risks.

 

The business case is often the gateway to getting a project off the ground. In many organisations it is like a key to the cheque-book—until the business case has been signed off work cannot start with any vigour. This leads to a useful focus on a business case early in the project lifecycle—which is a good thing of course—but once the cheques have been written, interest can start to evaporate very quickly. There is a danger that the business case will fester away, collecting dust in a document repository rather than being seen as a ‘living document’ that is central to the project and change initiative. This can lead to some very unfortunate outcomes.

 

A business case shouldn’t be “one and done”

Let Constraints See Daylight

Person looking through door at skyAs much as we’d all like to work in an organisation where resources are unlimited, time is unimportant, and our competitors move slowly (allowing us ample time to respond), the reality is often vastly different. In many industries, new technologies are allowing nimble start-ups to enter the market with different and sometimes disruptive business models. New channels mean that our competitors can reach clients in new ways—and our clients can interact with each other faster and with more transparency than ever before. Markets move and develop with increasing momentum. Just ten years ago, letting a smartphone ‘suggest’ a local hotel and taxi firm would have seemed insane. Today, it’s possible to book an entire journey with a smartphone, figure out which of your connections are nearby, book dinner and see what’s on at the local cinema all before you’ve boarded your flight…

 

In this constantly changing environment, utilising external environmental analysis techniques like PESTLE or STEEPLE becomes crucially important. Smart organisations will continue to regularly adapt, experiment and implement change with increasing speed. These changes can be small (perhaps a new incremental change to an existing website) or massive (cannibalising an existing product in favour of launching something completely new). These changes can affect any part of the business eco-system—the IT systems, processes, organisational structure, facilities, plant/machinery, products or proposition and so on. And increasingly this will involve liaising with skilled partners—internal or external—to help build, customise or buy elements of the final solution. It may involve procuring IT from selected vendors or services from managed service providers (MSPs), as well as engaging a wide range of internal stakeholders. It may even involve outsourcing or insourcing a capability.

 

In this race to get change implemented, so often, constraints get forgotten about. Or rather, with the fire behind us and with a strong sense of urgency, it is easy to delay a discussion about what will constrain us. Yet as alluded to in my opening paragraph, it is highly likely that we don’t work in an organisation where time, budget and resources are unlimited.

 

Leaving our constraints un-discussed and un-stated is akin to locking them in a dark, dank cupboard and just hoping they won’t affect us. We become like ostriches, with our heads firmly in the sand. Even worse, different stakeholders have different views over which constraint should be compromised. It is worth considering the traditional triple constraint of project management here. The Sponsor may hold budget as the most important unbendable constraint. The customer service team may feel that quality can’t be compromised on, with the marketing team advocating time as the most crucial factor. This is before we even discuss the rocky issue of scope as well as any other business or technical constraints.

 

Bringing constraints out into the daylight

Avoiding the Blame Game

In a previous article, I wrote about how outsourcing and utilising the skills of specialist firms, vendors and managed service providers (MSPs) can be an excellent way of gaining access to additional capabilities and expertise. It avoids the need to develop all capabilities in-house, and can enable focus to be retained on those areas where… 

Project Reviews and the Insight of Lessons Learned

Person about to step on banana skinI’d bet that everyone reading this article will have taken part in some kind of “lessons learned” meeting or brainstorm at some time in their career.  These sessions are often part of a retrospective or post-project review, and are aimed at ensuring that organisations and project teams consider what went well – and also what went badly.  The idea is simple: these lessons and pointers can be taken into account in future projects, iterations or phases.  This should ensure that future activities run as smoothly as possible.

 

However, it doesn’t always seem to work this way.  I was speaking with a contact of mine just the other day, who observed that in some organisations, the “Lessons Learned” process should really be called “Lessons Documented”.  He implied (only half-jokingly) that in some companies, learning points get written down but then fester in a document that isn’t ever read again.  The document might be loaded into a repository somewhere, but even if somebody wanted to read it, after six months everyone has probably forgotten where it is stored and what it contains.  The whole process becomes about ticking boxes on a plan rather than driving genuine insight and change.

 

This observation really resonated with me, and I felt he’d hit the nail on the head. If we’re honest we’ve probably all seen this pattern occur.  When running projects, there is the opportunity to capture valuable insight and data – everything from data about the amount of effort spent right through to insight about the issues that occurred and the problems that could have been avoided.  The challenge is that by the time the project is finished, everyone is tired and ready to move onto the next big thing.  Sadly, this might mean that rich insight is lost.

 

An example: Estimation

5 traps that will make “out-of-the-box thinking” fall flat

  • Adrian Reed 
  • 6 min read

Cartoon showing a manager encouraging the team to think out of the box, but deliver inside the box

We’ve all been there. A senior leader in an organisation gives a pep-talk about how she or he wants more innovative thinking in the organisation. We need to be brave, bold and ‘think outside of the box’. We need to brainstorm, ignore constraints, and come up with radical new ideas to solve problems and better serve the customer.

 

Out-of-the-box brainstorming can be a great way to encourage innovative and divergent thinking. It can be a great way to come up with completely new ideas in a supportive environment, and a great way to challenge our existing assumptions.

 

Yet I guess everyone reading this will have seen at least one situation where an organisation encouraged out-of-the-box thinking, but then delivered something very much inside the box.

 

Sadly, over time this can lead to real cynicism. You can almost hear that deep, cynical sigh from a co-worker that we’ve got to attend yet another “fluffy out-of-the-box brainstorming” session. It is sad that this happens, and it really doesn’t have to be like this.

 

So — why might efforts to encourage “out-of-the-box thinking” fail? Here are some situations I have observed with some potential ways of avoiding them. This list is by no means exhaustive, and I’d love to hear your examples too:

 

Trap 1: We’re not really brainstorming, we’re divining

Portsmouth's Spinnaker Tower

Deadlines are soon forgotten: It’s the quality they remember

Portsmouth's Spinnaker TowerThis is a picture of the Spinnaker Tower, located in my home-town of Portsmouth, UK.  It’s a 170 metre (560 foot) construction with viewing decks at the top that opened in 2005.  It’s a real tourist attraction and if you’re ever in the area be sure to go and see it – there are superb views from the top! (In fact, if you’re going to be in the area contact me and we’ll catch up for a beer…)

 

If you do visit the tower, you might notice that the building hides a rather embarrassing secret:  It was built with an external scenic lift (elevator) attached to the side that has never worked reliably.  There is an internal lift that you can use, but you may well notice a redundant lift on the exterior.  To my knowledge, it has never been opened for public use.

 

If you speak to the locals, you’ll be told anecdotes about how on its day of opening several people – allegedly including the project manager – were trapped in the lift for over an hour.   This has been a thorn in the building’s side for years, and the external lift is allegedly being removed.

 

I heard this story again recently, and it reminded me of something that should be kept firmly in mind when progressing projects: