I’m writing a new book, this will be my second*. I’d written a couple of chapters last week, one of which focussed on how organisations leave problems for the customers to resolve, but that they don’t think of it that way. In one chapter, I used the example of “Warning. Hot Water.” signs, stipulating that the organisation has decided that rather than fix the problem, they’ll leave it to the customer to work around the problem. Every day, every day they use the tap. When viewed like that, putting a sign up doesn’t really resolve the problem.
I was in a hotel at the weekend and I tend to think of hotels as having solved this particular problem a long time ago; it’s usually workplace offices that still have these signs. But enter the bathroom and it’s plastered with “Warning. Hot Water” signs. And it was seriously hot, close to scalding. For IHG, you’ll find this out when I review the hotel. It was just one of a list of issues. I travel a lot. I’m pretty flexible and lenient as far as hotels go. If there’s a problem, as long as it’s resolved, I’m happy. By that, I meant that I recognise that there are faults in any system, in any organisation and that’s ok by me. But if it’s a systemic failure, then I’m concerned. This hotel had a number of repeated failings. A quick look at trip advisor shows the issues are not isolated.
At what point does someone responsible for fixing a problem decide that a sign is enough? That the customer can have the problem? Did they work through a customer journey? Did they wonder what it would be like to be tired after travelling, hungry, thirsty, maybe a headache? Maybe not speaking English as a first language. Maybe not being used to English norms regarding taps (plumbing doesn’t seem to be standardised across the world)?
Why would we expect a foreign guest and customer to be familiar with the quirks our hotel’s plumbing?
Signs such as this protect the organisation. They inform the customer, but they do not remove the problem.
*If you’re curious why you haven’t seen the first book, it’s because I haven’t released it yet. The first draft is ready and I’m taking a short break from it to gain some distance before returning for the final push.
After a late evening fixing a plumbing emergency at home, I’m reminded of the concept of contingency and how it can’t be practically be used as a buffer for all non-planned events.
So with my current main client, I start out early in the morning, long before must people (or birds) have risen. My wife told me about an hour before I was due to go to bed early in order to wake early that we had an issue.
Applying typical contingency management as found in most projects wouldn’t help. That’s the type where a task is estimated to take 2 days, so you add in some contingency for that task. What would have happened in that case? All the tasks had finished, we were effectively waiting for a deploy (ok, it was a deploy of one person to a train, so I’m stretching the analogy a bit)
Applying a buffer contingency may have helped somewhat, but again, the tasks had all completed, there was no buffer to call upon before the deploy.
House alarms/Burglar alarms encourage similar behaviours. You only discover that the alarm isn’t working when you come to set it on departing your house. Again, no typical contingency would resolve the issues.
In the above examples, we’d usually have to add more time for the journey in the morning (possibly even travelling the day before). But the more we do that, the more ridiculous the timescales become and the demands on those involved become more exorbitant to accommodate for any issues. Even with buffer management, at some point we’ve passed the point where the buffer can be applied.
The only alternative that I’m aware of for this type of issue is one of preparation. It becomes more about damage limitation. So in my example, have I prepared for what I would do if I have to remain at home, if the train is delayed or cancelled, if the my taxi doesn’t arrive on time, if my car doesn’t start? Those are more the failure modes, as can be explored using an FMEA matrix for example.
From that perspective, contingency isn’t just a buffer (whether applied to a single task or applied to the project), it’s a behaviour and it’s planning about what if. It’s about ensuring that you know what to do, have the resources to do it and can execute in the time required, at whatever time it happens.
I’m divided in this, but lean towards only brief training, just enough to inform them, rather than enough to practice.
On one hand, it pays to understand why change in general is necessary and specifically, why the change that you’re about to implement is necessary. Often I see professionals who spend time with the person sat in front of them (and so they are patient-centred) but ignore the mass of people also requiring the same service. It’s not that they can’t see the queue (whether a real standing queue or a waiting list), it’s that if they recognise the queue then they realise that they can’t serve everyone to the same level. For some, it’s a question of professional ethics, where their professional body demands that they treat the person in front of them to the best of their ability, regardless of the needs of others. There are good reasons for that approach.
Usually, someone, e.g. a manager or budget holder, recognises the capacity issue and so increases the eligibility threshold or reduces the professional time available for that treatment. This is an attempt to average it out. However it misses the point that some treatments take time to work, if you half the time available, then you may get zero results, not 50% of the results had you allowed the necessary time for full treatment. It also leads to a worsening service as the capacity gets further reduced through a series of cuts, so that wouldn’t be the answer that we’d choose given a choice.
More fundamentally, the communities that the local and regional health providers serve are different to those that existed 30 years ago and the changed communities have different needs. So, it seems obvious that we have to adapt the service to meet the changed needs.
On the other hand, the health professionals are just that; professionals in health. There will be some with additional skills; some complementary, some tangential. I wouldn’t expect health professionals to be experts at change. However they do need to be aware of the change and why they have to contribute. As do we all, no matter what job we perform, no matter which sector we work in.
By recognising the above issues, we can more easily understand why we have to continually change. It’s a matter of adapting to needs. However that doesn’t feel like it requires a formal training in the guise of a university module, more an hour or so during induction combined with some questions during the interview to assess their attitude to change. I expect the professionals to know the service best, so they should be best placed to change it rather than having budgetary changes applied without thought to impact on patients.
To get this message across and gain acceptance and commitment from the group, I usually go through the need for change at the start of any change programme and definitely before each intervention.
One area where I think some training could be useful is in negotiating and debating how services will change. The changes will happen, but being able to influence the changes could be invaluable. Oddly enough though, it’s probably not the health professionals who need the training, instead it’s for anyone who’s trying to change the service, e.g. performance improvement staff, HR/OD, commissioners, etc.
I think the reason for my varied opinions above is that I see a difference between management and change management. I acknowledge that management techniques should be taught in advance as well as broad concepts of changes management, whereas the required, more detailed parts of change management can be taught as required.
I don’t believe we should conduct changes without speaking to the end customer. Taking on the role of patient, I’d much prefer the consultant to have spent their time learning how to treat patients, rather than learning how to manage change. Let’s permit some degree of functional specialisation, with front-line professionals continuing to be good at what they do and change professionals helping them create/design the service that the patients need.
However, I recognise that many front-line professionals either don’t have access to change professionals or do have access but that they’re not listened to. Hence the need for a book that’s applied for front-line staff.
Some organisations have a different approach to how they handle the status of a document. The approach belies a more fundamental culture of how work is commissioned and reviewed and how staff are viewed.
One of my clients exhibited odd behaviour regarding commissioning work and approving it.
Due to the nature of the engagement, decisions were made by me and then relayed to the client. That, almost unilateral, form of decision-making has not be the norm for my engagements. Instead, I’d have preferred to have reviewed the actions while I was working on those actions (rather than after the fact). It was all a bit backwards compared to any other client engagement, where we would address scope questions early on and progress from that more detailed, joint understanding.
Even though I was assessing business capability maturity, it felt contractual. I would have preferred a more collaborative approach, but the organisation’s approach to generating change was a contractual one. It’s an issue I’ve seen before but not as stark as with this client.
What I’d noticed with this client, was that if a document were released (no matter what version or draft status), it would be treated as final and published. The review comments would imply that the author had made mistakes and that it should never have been released in that format. Fortunately that didn’t happen to me, but that’s probably more to do with how I released documents. My documents had the same version control I’m used to including with many clients and consultancies. Draft documents (assuming little or no sensitive content) are published early to the intended audience for review, in order to influence the outcome and content of the report. The more sensitive the content, the more restricted the initial distribution and the earlier that guidance is requested.
With this particular client in mind, that approach would raise conflicting issues. The reviewers wanted to be able to influence the outcome of the commissioned work, due to the political status within the organisation. But the reviewers wanted to meet as a group to review the version, not necessarily as a steering group, to guide the work to completion, but as a review panel.
I had to tread carefully as to what documents I would release to anyone, regardless of draft status. While I’m used to not initially sharing electronic versions of documents with some clients, it was more important with this client. It created an odd culture, where people would complete work before releasing it, which then created rework and longer delays due to having to fit in reviews and changes.
Perversely, it also created a set of behaviours where many documents never reached a true state of finalisation or approval. Instead, they continued in some draft existence until ignored or replaced. That was a common occurrence, where I’d be looking for a previous strategy document, to find that it never reached completion, but became generally accepted as defining a destination or discarded. However, there had been no formal acceptance or rejection of the content, just a tacit decision across many people.
Reverse-Engineering the Culture
I think that much of the commission and review behaviour occurred due to the hierarchical nature of the organisation. That culture enforced a situation where superiors reviewed the output of their underlings. Couple that with an admonishing culture, rather than a praising culture, and you end up with a situation in which documents have to be final, or the critique becomes more about the person than about the document itself.
This was more than just a client seeing a document and then acting on it, treating it as a final document, e.g. to assist with negotiation or alter their position within the organisation. This was a systematic approach to not adhering to how artefacts are created and developed through to release and acceptance.
There was a severe hierarchy in the organisation where one grade couldn’t comfortably jump a grade when communicating, instead everything had to be passed up or down the chain. While organisations can work like that, many adapt and maintain the lines of communication even with flexibility and the exigencies of operating in any modern market. This organisation did not flex and those that did flex were generally put them back into place.
All of this led to gross inefficiencies and confusion due to navigating the corporate hierarchy. I’ll reiterate, the concept isn’t rare, but the ultra-strict adherence to hierarchy is rare.
This particular client compounded the inefficiencies from the hierarchy with the inefficiencies of poor document version management (or rather the document acceptance process), resulting in intricate, exhausting dance of what to share and what not to share, who to share it with and who not to share it with. All of this encouraged and promoted a contractual culture rather than a collaborative culture.
A number of years ago, I was transforming a city’s social care directorate and, as part of that transformation, we aimed to reduce the time it took to do anything when interacting with the service. The transformation was based on a more fundamental need to free up workers to be able to do the work they were meant to do rather than having to fight the fires caused by delays and resulting failure demand. I instigated a methodical approach for identifying which cycles to focus on first. As the team progressed through the cycles, I noticed a pattern; it’s the spike of activity followed by a lengthy delay as discussed in a previous article.
As we looked in particular at a few cycles of spike followed by a delay, I routinely advised the team to question the need for that common feature of bureaucracy: the signature.
Why require a signature?
In the case of social care, signatures are often required from service users or their representatives. This can be as proof that the content of a form is accurate or as a record of the service user providing consent (either for data to be shared from the form or for the authority to request data from other agencies).
These signatures create the spike-delay pattern in which a short spike of activity is followed by a lengthy delay while the authority sends the form to the customers and waits for the return of a signed copy. Part of that delay is caused by the postal service in both directions. Part will be the time it takes the service user to open the letter, read the form, make amendments, find an envelop and stamp and then go to the post box. Considering the high percentage of infirm service users compared to the general population, that sequence of activities can take a long time. Then we have the additional wait time caused by processing the response as it arrives into the authority.
So, my first instinct is to remove the need for a signature and thereby remove the need for the spike-delay round. This could be changed from requesting a signature to providing information on the form that the data will be used. If you don’t agree, don’t submit the form. The response from staff was that we needed the signature as a record of consent and/or accuracy, depending on the form in question.
On the fact of it, that seems a reasonable and fair response.
What does the evidence say?
However, the data showed a different reality. What actually happened is that, even if the form wasn’t returned, the process could still go ahead. True, it didn’t go ahead for every service user, but the fact that it could proceed implied that the signature wasn’t always required. Or rather, wasn’t required all of the time. We were able to look at the data to understand how many service users progressed without signature, we were able to look at common characteristics, etc.
By presenting this understanding back, we ended up moving forward in our joint understanding of the process; joint in that the consultant and the team had the same understanding. Before that point, they had had different interpretations.
So where does that leave us?
An undocumented process or exception is a risk. In the above case, we had uncovered that some of the cases were allowed to progress without signature, but there was no documentation defining which cases could proceed and which cases had to stop. Instead it was left to individual judgment, but again without defined criteria. So what happens if the usual staff members weren’t present? Were the decisions they made equal and equitable to all involved? How did we measure the outcomes?
Depending on the type of organisation and service involved, there will be a different focus regarding the risk involved.
In this case, we had a process with an unclear gateway, e.g. do we continue or do we halt and wait?
Complete the analysis in terms of understanding when the process can continue.
Engage with service users to understand what they need out of the process, what their engagement should be
As a team, choose a default option, either they progress by default or they pause by default
Help the team define the rules that govern the exceptions
Implement a training and induction programme for ensuring that everyone knows how to apply the rules
I always prefer the default option to be the one that improves efficiency, e.g. the one that’s the most common option or the one that removes a spike-delay pattern.
The wider understanding that, in most cases, the signature wasn’t required let us to a better solution. Had we not challenged either with data or further questioning, we would have been left with the difficult situation of lack of signatures stopping the process and the resulting action of requiring signatures in order to proceed. Instead by challenging the assumption and developing solutions to the issues of the spike-delay caused by several signatures for a sequence of documents, we were able to reduce the expected time from 6 months down to just over one day (actually 2.5 completions per week). That’s a massive difference in expectations for customer and the organisation serving the customer.
How long does it take you to do what your customers want? Not just the first part, but the whole of it?
1. The Pattern
I see this pattern commonly replicated across service industries. It involves a very short spike of activity (e.g. 5-20 minutes) followed by a lengthy delay where something is sent to the customer and the organisation waits for the return. This is followed by a 2nd spike of activity which in turn is followed by another lengthy delay. Depending on the bureaucracy involved, this process may involve several rounds of spike and delay, each adding to the overall delay in service for the customer and, most likely, increasing failure demand on the organisation.
2. Some Samples
Let’s have a look at a few industries and see how this pattern plays out:
2a. Retail Industry
Take for example, ordering a new item of furniture. We’ll start at the sales phase – although the complete process starts before then with marketing or customer acquisition – where the customer is in the retail store.
The customer, let’s call her Lilly, is buying a bed. Lilly spends up to an hour viewing and trying beds on a Saturday afternoon, talking to the sales advisor and then committing to buying one particular bed. The sales advisor creates the order, takes details in order to arrange finance, takes some information regarding proposed delivery times.
This is the first spike. There may be finance involved and almost definitely delivery involved. Lilly is told that the delivery company will contact her by the end of the week. That’s the first disappointment, can’t they arrange delivery now for later that week? Instead, she begrudgingly continues with the order hoping for a delivery time that meets her needs.
Some customers stop the order and go elsewhere. They’ve arrange finance, but may not have committed at this stage. For Lilly, who continues with the order, she goes home, then spends her week as normal waiting for the phonecall. This is the first of the delays. In Lilly’s case, the delivery company ring her on Tuesday, two working days after the order. Two days is a long time when you’re waiting. And it’s definitely a long time when compared to the processing time in the showroom on that Saturday afternoon. So it would not have been surprising had she rang the salesman on Monday or even Tuesday morning, creating failure demands disturbing him from achieving more sales.
The delivery company have a van that delivers to Lilly’s area on Tuesdays but she’s missed the delivery for that week so it will be the following Tuesday. This is the second spike followed by the second delay.
The week passes and Lilly receives the bed at her house. She finds there’s a part missing and calls the number. There’s a spike of activity as the after-sales staff figure out what’s missing, decide what to do with it and then initiate that action. For Lilly, it’s a small part that’s missing, so they’re going to post it to her. A few days wait ensues and, on Saturday – that’s 2 weeks after the order was placed – she receives the part.
It’s broken, either in the post or during the picking process. Again she calls the after-sales and they go through the same conversation as the previous week; this time a bit more aggravated. The part arrives intact on Tuesday and 2 weeks and 3 days after the initial order, Lilly has her bed.
If we take into account a pro rata of the delivery effort, we end up with about 5 hours activity across 17×8 hours = 136 hours. That works out at 3.7%. If we look at the actual value-add activities rather than all activities, that’s probably a lot less (i.e. the original order time plus the delivery, but not arranging the bed delivery or arranging for delivery and redelivery of the missing part). Let’s say that’s 1.5 hours including ordering, picking and delivery that works out at 1.1%. That also assumes that we’re looking at working day hours, not full 24 hours as customers are becoming more accustomed to. Had we considered 24 hour days for 7 days a week, that 1.1% reduces drastically.
2b. Service Function
Michael is returning a bluetooth speaker to an online retailer. It’s Saturday evening but, like most, the website is 24×7. First he logs onto the retailer’s website, looks at his past orders, finds the order for the bluetooth speaker and submits a complaint. This is the start of the RMA process that’s commonly used for returning (technical) goods.
On Monday afternoon, Maria a member of the service function, replies to Michael’s email. Maria expresses regret about the fault and attaches a fault reporting form for Michael to fill out. Michael’s a bit annoyed about this; he’s already provided some of the information in his original email to the company. However, he does accede that they will want some additional information in the form.
He has to print the form but he can’t do that until he’s next using a computer that can open the pdf document and print it to a nearby printer. So on Wednesday evening, he prints the Fault Report form, writes the details and then scans it. He emails back the completed form that evening.
On Thursday morning, one of Maria’s colleagues, Zoe reads the form, agrees that the bluetooth speaker is faulty and then sends Michael the RMA note, authorising the return.
Michael has to print this out, so again has to be next to the printer. He does this on Saturday morning, boxes up the speaker and posts it on Saturday afternoon. The parcel arrives on Tuesday morning, opened by customer returns who agree with the fault, authorise an exchange to be sent to Michael and inform Michael of such. Michael reads the email on Tuesday afternoon, around the same time that the warehouse dispatch his replacement to him.
On Friday morning, the delivery company attempted to deliver the replacement speaker to Michael’s address, but as he was working, it was returned to the depot. “Fortunately” for Michael, the depot is open on Saturday morning, so he drives to the depot and collects his blue speaker. That’s not really fortunate since a better solution would have been to have checked with Michael when he would be available to receive the package. But it could be worse, the depot could work standard mon-fri office hours.
Almost 2 weeks have passed since Michael reported the initial fault, with more effort required of the customer than of the retail company (so far). Michael has probably spent 4 hours of his time in sending emails, reading emails, printing, completing forms, boxing, arranging for delivery and subsequent collection. The retail company spent 3 minutes in the initial fault report form, 3 minutes reading the fault report form, 5 minutes arranging for the RMA, then 5 minutes despatching a new one. Less than an hour. They’d also have disposal or return of the fault item plus accounting and other supporting activities. However, having spent less than an hour of “value” time in the returns process, the company managed a process that took two weeks. The ratio of value added activities to the length of time to complete the process is low, 1 hour to 24 hours x 14 days = 0.29%. That’s not uncommon.
2c. Local Authorities
This is where I first encountered the pattern. Instead of writing about it in this article, I’m going to save it for its own article as I’d like to explore it in more depth. The pattern is rife in local government and related services. I’ll post a link here when the article has been published.
3. The Calculation
There’s a term for this concept and formula for calculating it. It’s called CPE for Cycle Process Efficiency or occasionally PCE for Process Cycle Efficiency.
In this case, I’m calculating the time for the whole end-to-end service process. If our examples are consistent, then the service function is showing a Process Lead Time of 2 weeks per unit. That’s the elapsed time it takes from the point that the customer first contacts us to the point that we deliver the solution back to the customer.
We also require the Value Add Time, i.e. how much time per customer is spent creating or transforming value? This may actually be easier to arrive at the Value Add Time as equal to the Process Lead Time minus the Non-Value Add Time. It’s often easier to identify the steps that do not add value. Whichever route we take, we’re aiming to identify the Value Add Time for this process.
The PCE is then the Value Add Time divided by the Process Lead Time. It’s usually way lower than you initially think. If it’s above 70%, then you probably haven’t identified all the non-value add steps. To put that statement into perspective, I’ve seen PCEs lower than 1% for appallingly bad processes and improved them to 25% for a drastic improvement. Unfortunately, finding PCEs <1% is not that uncommon.
So what can we do about the pattern?
1) Recognise if the pattern is active in your organisation’s services.
2) Focus on the delay. You’ll almost always achieve more value and improvement from resolving the delays since they outweigh the spikes.
3) Consider different methods for removing each round of the spike-delay pattern.
For example, in the returns process, the fault reporting form could be on the website, ready for customers to complete. In addition, the organisation could implement automated authorisations when submissions meet certain criteria. This could include printing returns labels on the invoices packaged with the original goods. That would be 2 of the rounds reduced.
There’s no question about the fact that fixing the problems so that they do not happen again is the most important step and will have a greater impact on CPE than any factor. However some of the above issues with CPE don’t involve a failure (such as a defective part), but are due to the inefficiencies present in the process. These are often caused by a bureaucratic need to manage risk. The question then becomes one of addressing that risk through other methods.
Do you want to comment, get in touch at @alanward.
I’m going to use GDPR as an example of how prioritised goals can make a big difference in how an organisation responds to change. I’ve no wish to jump on the consultancy bandwagon that is GDPR; I’m definitely no expert on the subject. However, GDPR will serve as a good example in this content as it’s a topical subject that many organisations are addressing and so should be at the forefront of many strategic and tactical discussions.
A brief perspective on GDPR
I have a simple view of GDPR in that it’s requiring organisations to be better citizens, i.e. to behave better with the data that they obtain and manage. While there are a those complaining about the effects of GDPR, I would first want to question the motives of the companies they work for. I would be looking to see whether the motives are customer-centric or profit-centric. For most customer-centric organisations, most of GDPR is doing what they do already, but with some more rigour to their processes. Unfortunately GDPR is a bit of sledgehammer and a few other nuts will get cracked.
GDPR has stronger implications for what can be done with customer data, potentially rendering data useless collected in such a way. Actually, it goes further in terms of legality of handling and processing data, but we’ll stick to usefulness to the company for now. The important point is that for many companies, there will have to be some changes to how they collect data in that manner and potentially if they continue to collect it at all.
Business Motivation Model
So let’s apply business motivation model and see what GDPR looks like in this case.
The above diagram depicts two companies. One on the left and one of the right; there’s a gap between the top. It is a simplified business motivation model showing the difference between the two organisations, based on one single goal at the top.
For the left-hand company, the main goal is to Provide the best customer service possible. They are achieving this through a sub-goal (maybe a mission in many organisations) of Build relationships with customers. This goal is achieved by the outcome of Capture Customer Contact Details. I’m simplifying to allow outcomes as measurable effects that will happen.
The outcome is realised by a process group of Ask for details of customer which is part of the Pre-GDPR state or plateau. That process group fulfils the outcome for the situation before GDPR. We’re interested in what happens in reaction to GDPR.
In the same company, we can see GDPR as a external driver. The company conducts an assessment and we have a goal of Be GDPR compliant.
That goal influences Capture Customer Contact Details.
We have a work package designed to achieve that goal of Become GDPR Compliant.
For the Post-GDPR state, notice that there is a revised process group of Revised Customer Engagement. This process group focusses on building the relationship. It’s implemented by the Become GDPR Compliant work package. You can trace the line up to the goal of Provide the best customer service possible and the driver of GDPR
Meanwhile, on the right-hand side, we see a similar motivation model, but with some differences. The GDPR elements remain the same. What has changed is the overall goal of Increase Revenue which includes the sub-goal of Increase Revenue from Individual Customers. To achieve those two goals, we end up with a different process group for the post-GDPR state. The result is the same as the original process, but prefaced with an explanation of what we’ll use the data for, etc.
The Business Motivation Model was simplified in this case. I’d expect to see design principles/constraints, more detailed goals and objectives on the company-side and more detailed goals and objectives on the GDPR assessment side. All of those would constrain the future design.
For instance, the revised process groups I’ve displayed are not the only options that meet the listed goals. However with more goals and outcomes included, I’d expect there to be fewer options to choose between.
The examination of the GDPR scenario through a Business Motivation Model indicates at least two responses to a common data collection issue.
The end result is that it:
may speed up queues since companies realise they can’t just ask for contact data and they decide to not ask,
may speed up queues since companies realise that the interaction doesn’t allow for valuable data to be collected since they won’t have an agreement to use it and, again they decide not to ask, or
may elongate queues so that the companies can ask for permission
Back to the title, I see options (1) and (2) being the white knights for the customers of many companies. We’re hoping that companies follow common sense and implement changes that both respect the customer experience and adhere to GDPR. However in addressing the elephant in the room of how processes can be changed to suit GDPR (rather than improved for the customer), we may end up with (3) and a worse customer experience.
I’ve got some time in between clients where I’d like to contribute back or pay-it-forward. I’d like to donate my time for free and raise a bit for charity while I’m doing it.
What’s the offer?
You get a Business Architect for free*
*What does free mean? You don’t pay for my time. Instead, you pay expenses (we can agree up front and they could end up being zero) + you make a donation to a registered charity (I’ll leave the amount up to you).
You’ll get me for up to a day, plus time beforehand over email/messenger to discuss how to use that time.
Alternatively, if you just want a chat in person/over Skype, I’m happy to get involved.
This is open until Fri 25th August 2017 to one more company or organisation initially. I have one already booked in, so there’s one more space.
Business Architecture is an odd profession. The common route in is through strategic application of many different business analysis methods, but it is possible to come in through other routes. Which means that no two Business Architects have the same skills, experience or expertise.
I specialise in three areas:
Innovation: specifically bringing activities more commonly related to startups into larger organisations, kick-starting innovation if you’re just starting, have stalled or hit a brick-wall
Customer Focus + Lean: evaluation of your current operations, plus how to transform them into something more efficient and relevant to what your customers require
Motivation: specifically Business Motivation rather than individual motivation, although the two are closely related.
The trick would be finding something that we could achieve in one day. I’m up for that challenge. Are you?
If this works out well, then there’s a good chance that I’ll do this on a regular basis. So please, get in touch. Even if we don’t meet this next time, I’ll remember you for the next round.
I’m convinced that there’s no thought to place of people in the design of most supermarket car parks.
I’ve just been to a great example of poor design.
When driving in, you turn off the main road to a roundabout. At this roundabout, you turn right, away from the store, to the main car park. You can turn left, towards the store, to the disabled and parent+child spaces. There is no path between the main car park and the store. So at the roundabout, we also have people walking from their car to the store and back from the store, laden with shopping, to their cars. All those people also have to walk through the disabled and parent+child car park. Even in that car, the only two differences are that the spaces are wider and closer to the store. Once you’re out of your car, there is no pathway or walkway, even as disabled or with a child; you’re straight into route of cars (with their drivers looking for spaces).
More Common Example
I’ve always wondered why every supermarket car park has the access road running right past the front of the supermarket pedestrian entrance. From a day-to-day safety perspective, it doesn’t make sense. It forces drivers to drive their cars past pedestrians trying to cross the road from the car park to the store. It feels like lazy or shoddy design. I hope that it’s a law or bye-law regarding providing access for emergency vehicles. However, even if that were the case, is the road right in front of the superstore the correct approach?
What’s missing here is the realisation that we’re all pedestrians. Whether we drive or not, at some point, we’re walking or moving with the aid of a wheelchair. That element has been forgotten and instead, the focus has been placed on the car, not the people.
Cars can’t speak for themselves, they can answer questions in a design sprint. Only people can. And there will always be more people than cars going to supermarkets. At least, until automation becomes more prevalent.
Can you imagine what a car park would look like if it were designed with people in mind first? Better walkways, better trolley parks (self-driving trollies?), more visible paths splitting pedestrians and cars, straight walkways that go from the store to where people want to get to (as opposed to the current approach of pathways where it’s least awkward for cars).
I remember one of my clients being confused when I mentioned the carrot and stick as we discussed motivation for change. Since then I’ve found it an interesting test to see how people think motivation works in their immediate team.