IDEFlite is the perfect way to communicate how a business process, and any underlying automation, is going to work between technical and non-technical audiences. This makes it an ideal point of reference throughout a project.
Audiences can use it to describe ideas, changes and potential issues in a way that reduces misunderstanding.
Unlike the typical flowchart modelling techniques, found in technical developments, IDEFlite is ideal for creating a high level view of a business process. It does so in a way that is easy to understand for anyone who needs to look at and comment on the model.
What is IDEFlite?
Based on IDEF0, IDEFlite is a simple, yet powerful, way to model activities, workflows and activities. It’s simple in that it uses a very limited notation which makes it easy to read for anyone.
While being very simple it can be used to describe extremely complex scenarios using decomposition. That is, every single activity can be described in more detail whenever required. Without the need for a complex library of descriptors.
When compared with IDEF0 one can see the primary difference is that IDEFlite does not make use of Controls and Mechanisms. Instead it focuses on Inputs and Outputs while including a human role.
How does it work?
The Building Blocks
Work is described as activities.
Every activity should have at least one input and output to set the scope of the work. All work should be owned by someone in the form of a supporting resource.
Activities are Linked Together
Work activities are linked together to form flow diagrams (processes).
Activities are Deconstructed to Form Hierarchy
Work activities can be deconstructed thereby creating a new detailed view of that activity. This forms a hierarchy of detail linking high level activities with low level tasks.
This is done when it is necessary to describe an activity in more detail. For example during a conversation about how something works. If the current flow does not adequately describe a particular interaction the user can take that step and create a detailed view.
Each level of detail is a new diagram, together this collection of hierarchically linked diagrams is a map.
We’ve never wanted to sit still and we’re always looking for ways to improve our company, our services and our products. Earlier this year we released the latest version of our Skore web application. This included an almost complete rebuild of the whole app from ground up.
It’s no small undertaking to start from scratch but we felt the time was right. As you develop a product there’s lots of trial and error, some things work well others, not so much. Feedback from users is essential but so is our own experience using the product. And this is something we pride ourselves on, we use our product on a daily basis.
But it’s not just user experience and usability changes that are important. As we develop the software we learn what works and what doesn’t. We realise that some choices, that seemed right at the time, have challenged us later on. This is why it’s important to take the opportunities to rebuild when they arise. To apply, from the beginning, all the lessons we’ve learnt since the last time.
For those that have followed us since 2014 they’ll know that this isn’t the first time we’ve rebuilt the product, or redesigned the user interface. Here are some of our previous user interfaces that some users will remember, some more fondly than others!
Skore Prototype
While not the very first prototype you can see one of the first uses of the what and why boxes. The product was then called Score with a C. All the main controls are there which allowed us to start testing with real users before we officially released.
Skore Version 1
Our first official release of Skore was for the desktop only. The interface was simple, there was no way to apply styles to the content. The editor tool bar was along the top of the application rather than the left bar we use now. By this time we had added the sticky note feature that allowed the user to annotate process models.
All the key features were here by this point, rapid modelling, shortcuts, multi-layers and attachments on each box. Although in version 1.0 you could only share processes by PDF or with other users of Skore desktop.
Skore Version 2
Following a business review with the Happy Startup School we underwent a rebrand, new logo and website. Then we decided to follow up with a redesign of the Skore user interface.
We worked with Mike C from Think.gg to design a new interface with darker colours contrasted with the green we had adopted in our logo and website.
We implemented a bright fun backdrop to the app which proved controversial. Some users loved the playful background and others immediately asked us to remove it. We quickly implemented a configuration item for those that weren’t fans.
By this time the app had implemented stylesheets that let users change the look and feel of the visualisations, add images or choose from the library of icons.
It was shortly after the release of this version that we started working on our first web app. To get up to speed as quickly as possible we build a separate backend web application and graphted the new Skore editor on top of it.
One of the biggest challenges for us is that we used different teams, and different designs, for the main web interface and the editor interface. These were completely different apps that had been integrated. It soon became clear that we’d need a complete rebuild to resolve the increasing technical debt that had built up.
Skore Version 3
Back in late January we released our Unity interface, or Skore version 3, which brings all parts of the application into a single design. This version of the interface has undergone the most extensive user testing to date. This led to a standardisation of common functions such as Search, New, Edit and Save across each type of content in the workspace.
The interface also came in time for our new branding which was easily implemented into the system.
This is a great step forward for us, it demonstrates our commitment to continually improving the product. It’s not just the interface but the rebuild ensures we also constantly update and improve the architecture, security and performance of the application.
If you would like to learn more about Skore why not request a demo.
At the heart of an agile organization is a deep understanding of how we work together. In an agile team, the constant collaboration between the members help doing so. Retrospective meetings are the institutionalised forum for talking about “how we work”. In reality, every time people talk together there is a little bit of “how” in the conversation. How many conversations end with “you do this, then I do that”.
There is little need to formalise processes in too much details at a team level. This is compensated by clear and open communication between the members.
Do you need processes at an organisation level?
This gets more complicated when several teams are working together (team = sharing coffee machine). Such as procurement and production; or sales and accounting. Or Head office – regional offices.
At this level, the interactions are less regular, and, we do not systematically voice concerns or “just” change how things work. Processes change are often heavy and it’s easier to not do it.
This is where process definition gets critical to understand how things work. And this is where you need some sort of governance to make it right, especially around change.
What is process governance in an agile organization?
This post finishes with a list of open questions / thoughts because I don’t have a definitive answer (yet).
Create a system that allows continuous improvement (CI) of processes (willingness to do so, and an approach to make it) at cross-functional level
Create the incentive to do CI across several teams (incentive = people will find the time to do it)
Have a common language to describe the work so that everyone can prepare in the best way (Hello, Skore)
Process owner is key role to make that happen
Middle management is a key role to make that happen
Good understanding of outcomes of the process vs. outputs to be in the right context
The key seems to be to create “space” in the organisation for continuous improvement activities…
A gathering of business change and improvement professionals in an open discussion where ideas are shared and questions are answered. A Skrum typically takes the form of three talks followed by discussion, questions and networking. Talks are 20 minutes long and cover topics such as project insights, case studies, methodology and technology reviews.
Partly inspired by Product Tank, product management meetings, and by our network of partners we decided to start hosting our ‘Skrum’ meetups this summer. When we meet individually with partners and customers we have some great discussions and always learn something new.
But we realised that there was a lot of similarities between the discussions we were having. So why not bring some of these people together to have the same conversations and share their experiences in order to help each other learn?
And so Skrum was born, a small(ish) gathering of practitioners in a room together to explore topics that can benefit and help in their own projects.
To bring a bit of structure to the events we decided to shape it around a series of talks that allow us to discuss these topics from different angles. Each session we try to have one talk from each of these areas. The main areas to date are; Project Insights – a case study or introduction to a particular project you have worked on. Methodology Review – an overview of a tool, or framework, you have used successfully. And Technology Review – an introduction to a relevant technology that has helped you deliver a project.
So far we have held our meetings in central London but we plan to run more in other cities. In fact our next meeting will be at our headquarters in Portsmouth on the south coast of England.
If you’d like to get involved and learn more about our upcoming events then why not join our meetup.com page.
As a Business Analyst, or Project Manager, you often arrive on a new project and have no idea where to start. Things are a bit chaotic for a few weeks and then they gradually start to fall into place. You all figure out your roles, what needs to be done and the real work can begin.
This frustrates me, it’s wasted time, we should be able to start adding value straight away. I think… what would Bear Grylls do on his first day on this new project?
Dropped into the desert, or a high mountain peak, out in the wilderness. He has to get to civilisation and he has to survive using what he can carry and the environment around him. If he doesn’t figure this out quickly he’s got more to worry about than the failure of the project or the termination of his contract!
The first thing he has to do is assess the situation. This isn’t a random investigation but a structured approach that can be applied to a variety of environments so he can quickly start making important decisions.
He’ll look at the sky, where does the sun rise and set, roughly what time of day is it. He’ll look at the ground, are there signs of a water source, what way does the ground slope, are there visible peaks and so on.
Only then does he start to move toward his ultimate goal… civilisation.
A model for better business performance
Over the past few years I have been educated on, and adopted, an organizational performance model (OPM). This has really helped me make sense of a current situation and focus in on problem areas when I arrive on new projects.
This OPM is used by some of the world’s largest companies to understand business performance and improve results. The great thing about the model is its simplicity, but more importantly how it puts everything into context.
The Organization Performance Model (OPM)
When assessing an existing organization, or process, we look at the relationships between each of these areas. You can start anywhere in the model and move clockwise around it to make your assessment. Although I prefer to start at Business Results as these are the results you are most likely trying to influence. Moving back from here you can start to ask why do we see the results we see.
Once your assessment is complete you can begin the design phase, working anti-clockwise around the model.
Business results
The business results, as mentioned above, is about looking at what results you get today. It’s important to understand these so you can measure how they change as a result of the project.
Culture
This describes the values, beliefs and the actual work that people do in the organisation. It’s this that drives the business results. It’s the reality of what people do every day.
Design Elements
The design elements are the structures, such as described processes or org charts, that should influence the business results. Understanding the relationship between this and culture is essential in changing the results. A perfectly designed process is useless if no one follows it.
Strategy
Design elements should be aligned with the strategy. This relationship is often broken as a result of a poorly defined ,or poorly understood, strategy.
Business Environment
The business environment includes factors often out of your control. It may include the market, the competition and the behaviours of consumers. Understanding the business environment is essential before defining an effective strategy.
A simple assessment of these five dimensions will help you focus on the key areas that need attention and the order in which you tackle them. Once you have the results of the assessment you can start working immediately.
If you would like to learn more about how we use the organization performance model (OPM) above please get in contact [email protected].
“The reason most process led change projects fail is that they ignore culture”
I was listening to this during a programme meeting. Some consultants had come to present to us a sure fire way to deliver a successful programme through a focus on cultural change.
My colleagues around the room were all nodding wisely but this statement made me feel a little uneasy. What is a ‘process led change project’… and just because this person says they ‘fail’, do they really?
The conversation moved on to how this approach worked, a ‘process’ they employed to drive cultural change. There were a lot of group meetings, holding hands and singing and somehow the programme would be successfully delivered.
Don’t get me wrong, there were a lot of useful techniques being discussed to help us engineer a culture for success. However, we came back several times to why process was bad. People don’t engage with it, it’s confusing, it’s too rigid and documenting this stuff takes a lot of time.
Just as we were about to throw the baby out with the bathwater I was suddenly inspired by Daniel Pink’s talks on motivation. I remembered a scene where he talks about the contradiction of money as a motivating factor. He describes how money only acts as a motivator up to a certain point. Then its effectiveness drops off and other means are required to motivate workers. He goes on to say “pay enough to take money off the table”. Then you can focus the conversation on other factors such as empowerment, freedom, flexibility, all the things people aspire to once they can pay the rent and put food on the table.
It struck me that process is the same for a change project. Change almost always results in a change to the way we work, the way we do something at work. Therefore process is an essential part of any change.
Just like workers are unlikely to turn up for work in a profit making business without getting paid, a change project isn’t going to work without understanding how things work today and how we’re going to change them tomorrow.
Conversely too much process (too much detail, too much control, too much analysis) will put people off, constrict them, take valuable time away from them. And ultimately impact the successful delivery of the project.
What we need to do is focus on taking process off the table so that the rest of the programme team can focus on all the other aspects of the project in order to engineer a culture of success.
What does that mean exactly? It simply means we help understand the current state in a clear and simple way (even if that means the current state is incredibly complex). Processes should be captured in a way that all members of the programme team, and stakeholders, can use it to communicate effectively.
If process documentation is difficult to read and understand it becomes a barrier and that means it’s still very much on the table as an issue.
The documentation should be at the right level of detail: too much and it becomes too restrictive, too little and it doesn’t provide enough guidance.
Design and validation of changes should involve key people that will help drive the change. If you want to empower people try to get them involved in the design. You can’t include everyone so make sure there is a clear and simple way that everyone can be heard and provide feedback and ideas.
Finally don’t fall in love with the first version of a process you capture. Make use of the freedom to capture multiple versions of the same process and ask people what works well and what doesn’t. The best ways of working will emerge as others share ideas and feel free to discuss how they do it.
Want to learn more about how Skore app can help you take process off the table? Contact us [email protected]
We’ve shared before a high level process for implementing software but here I thought it worthwhile spending a bit of time considering how we select the right tool in the first place.
Over the past few years we’ve worked with a number of small to medium sized business implementing new systems. In many cases they have already selected a tool and are simply asking for help getting it setup and running.
It begs the question, if they don’t have time to implement it where did they find the time to choose it?
Choosing the right software is just as important as the implementation. In fact much of the work you do during selection is required for the implementation.
Our experience demonstrates this issue as when asked to implement, without selection, we often discover too late that the new software is missing some critical feature.
Here is our high level process for selecting the right software:
click the image to view the interactive process
How it works
It goes without saying that a core part of this approach is the capture of process! But only once you’ve defined the objectives, goals, benefits (perceived and real) and, importantly, budget.
These things are essential up front. They may change as you learn more about the solutions you are reviewing but you need something upfront to frame the next conversation.
Work with a number of key stakeholders to capture and understand the current process. This allows everyone to get their concerns, hopes and desires out on the table and documented. In the context of what they do and what they are trying to achieve.
You now have a heap of really useful information that will certainly make your early selection easier. You can start researching potential solutions. Simple things like budget and a rough list of requirements will help you eliminate those that are too expensive or don’t deliver your basic needs.
Getting into the detail
Now it’s time to get hands on with your shortlist. Before signing up to any trials you want to create a couple more resources. Firstly create a list of scenarios. Work with the stakeholders again to understand what are some common and not so common scenarios they deal with.
Here are some example scenarios from a software company looking to implement a support desk system.
User from a small customer calls in to say they have forgotten their password
User from a medium sized customer calls in to say the system is unavailable, they are upset and losing money
User calls in with a question about a feature that is detailed in the help manual
etc
Discuss how these things are handled today and what rules are applied. I hope you are starting to see that you are gathering lots of really useful information here and keeping a track of all the requirements the team have.
It might be worth using Kano mapping to categorise each requirement in terms of ‘must have’, ‘nice to have’ and ‘delighter’.
This list forms the basis of your comparison chart. Create a matrix with requirements down one side and the shortlisted solutions along the top.
As you evaluate each solution against your scenarios mark each requirement with a score (1-10 typically works well) as to how well it met the requirement.
Once the evaluation is complete you can add up the scores. Don’t forget to make notes about other features you find along the way and the general experience.
Create a report
At the end you should be able to present your findings back to the team with both quantitative and qualitative analysis along with your recommendation for the product.
Explain how the solution stacks up against the original goals and objectives. It’s possible that none of the solutions fit perfectly, especially if budget is constrained. It’s up to the business owner to make the final decision.
I hope you find this useful. If you’d like any further guidance please contact us [email protected].
I was on a call and we had this discussion about, supposedly, 2 types of processes:
Process as a “recommendation”: process says A-B-C but you can do A-C-B if you think it’s relevant. Maybe it’s good for a project.
Processes as mandatory instructions: process says A-B-C, you must do A-B-C. It’s best for repetitive processes that need a lot of structure.
Ok… so one is more flexible than the other?
In (1) people use their expertise and experience to know what is best to do and adapt the process to their needs to get the best performance.
In (2) people use their expertise and experience to know that it is best to follow the process in order (A-B-C) to get the best performance.
So to me there is no such thing as a process for “repetitive / structured” activities or a “project process”. We rely on people using the process to know when to adapt and when to comply. The end goal being the same : how can I get the best performance.
We are in the business of creating shared understanding between functions so they can work together in the best way.
Describing a way to do a project as a process helps understanding all the tasks of the project and how they are linked. The role of the project manager is to understand these tasks and coordinate them so they produce what needs to be done.
In this video I take you through a demonstration of an example process and procedure portal created in Skore app.
Traditionally Skore app has been focused on process design and analysis with our view on making it as quick and easy as possible. As we worked with more and more teams they told us that creating documentation with the process information was also very important.
Once you’ve designed a great process it is only really great if your team use it. We provided tools to help create documentation such as image export and save to PDF but we really wanted to do something better.
With Skore app you can create ‘easy to read’ process flows that tell you what happens, who does it and what outcome should we expect from each step. Process flows present the steps visually which makes them easy to follow, especially if the process has choices, alternatives and branches.
On to this we can add further information, detailed descriptions, images, video, audio and links to systems and documents. This means that the procedure is no longer just a static document but provides access to all supporting information presented in a clean interactive flow diagram.
Check out our Learn pages to find out how to build Rich Interactive Procedures in Skore app.
Ever wondered what’s going on after you’ve repeatedly had a bad customer experience with the same company?
How do companies allow themselves to come bottom of the pile in consumer research with the most complaints or the longest call waiting times?
Here’s why that happens and what companies can do about it
These are often larger known brands that rely on a large market to provide them customers. In today’s connected world a bad experience quickly spreads across social media and makes it into mainstream press faster than ever.
So how can these brands allow this to happen? We may think they don’t care, they’ve developed a culture that doesn’t respect the customer.
In the most part that’s not true, employees, managers and leaders want to be successful. The company wants to protect its brand and, in the age of the consumer, it knows it must provide the best service it can to do so.
So why does this keep happening over and over again?
Disruption
We don’t always see the same brands making the headlines, although some are more persistent than others. Generally those that are top of the consumer research ‘worst’ polls won’t be there next year, in fact they are often at the opposite end of the scale.
This shows that most of these organisations take the problem seriously and try to fix it. But how or why do they let it happen in the first place?
These spikes in bad performance are often triggered by a disruptive event. Something unexpected the company wasn’t prepared for.
For example, in a recent interview I had with the Operations Director of a leading energy company he explained that customer growth had taken them by surprise.
“We introduced some new, very competitive tariffs. We expected an increase but nothing like what we saw.” He went on to explain how they made headlines “The number of calls shot up and many calls were dropped due to the sheer volume. This in turn meant customers called in again and things just kept getting worse.”
It wasn’t just call waiting times that were affected. The increase in pressure on the team exposed gaps in their processes. The Customer Service Agents were no longer able to provide the same amount of care to each customer as they normally had time to.
A lot of balls were dropped and this led to a number of complaints making it into local and national press.
Another client I worked with in the telco industry suffered both internal and external disruption. Under two separate strategic initiatives the company created the perfect storm of ‘change fatigue’. The support desk at the centre of these two initiatives was barely able to cope when a major fault erupted on their network.
The call volume spiked and the disruption caused by the two change programmes meant they were unable to get control of the situation and bring the call volume down to a manageable amount over the short term. This led to a number of major customers threatening to move to alternative providers.
In both these cases the short term solution was to throw bodies at the problem. More Customer Service agents Were hired to clear the call volumes and bring things back to normal.
What went wrong
As business returns to normal the old habits return and things carry on until the next major disruption. Everyone breathes a sigh of relief and carries on as they were.
The real underlying problems were acutely obvious just as things got out of control. In those moments immediately before chaos ensues. There is a frantic scratching around to find the answers to questions before we revert to taking the simplest path.
For every individual this simple path can be different. Send it on to your colleague and forget about it. Make something up that sounds plausible. Say what you ‘think’ the truth to be without taking the time to check it. As things get worse we stop asking, we stop seeking answers and just do whatever seems most likely.
When we stop following the process we can’t expect the right outcome to be delivered. In fact we can’t expect the outcome to be the same for each customer interaction.
The vicious cycle of customer experience
When we trip on a staircase the natural reaction is to grab the handrail to steady yourself. But if that handrail isn’t there we grab out at the nearest thing, the wall, a colleague or stranger standing nearby. Like the safety demonstration on an aircraft we aren’t expected to use these things all the time. But they are there whenever we really do need them.
It’s these ‘safety features’ that are often missing in our work that should help us deal with unexpected situations. Like the procedure document created for the last audit and left to collect dust in a filing cabinet, the lifejacket under your seat may as well not be there if you weren’t reminded about it every time you got on an aircraft.
And so this is what happens in a time of crisis. When things start to go wrong and there’s no obvious handrail to grab on to employees will grab whatever they can.
In the examples above this suggests the systems, and therefore the underlying process, were not fit for purpose. They didn’t help the team, they worked against them. This doesn’t fill your team with confidence, especially in times of high pressure.
When this happens it has an impact on employee satisfaction, a key part of delivering a great customer experience. If your front line staff aren’t happy it’s highly likely that will eventually affect customer experience.
Take this together with a worsening situation where the workload is going out of control. Add the fact that customers are becoming more and more frustrated as they are made to wait in endless queues listening to the same maddening holding music over and over and over.
A frustrated customer and an inability to effectively resolve that customer’s problem creates the perfect storm or vicious cycle. The vicious cycle of customer experience is when poor customer experience and low employee satisfaction reinforce each other in a downward spiral.
The vicious cycle of customer experience
The image above shows the various interactions in play that can lead to the vicious cycle. Keeping all these things in balance is important to maintain a healthy team.
Being prepared for disruption
As we have seen, under normal conditions a balance is found in the system allowing customer experience and employee satisfaction to stay relatively constant. However, the more ‘brittle’ that system is, the fewer safety features it has, the more likely balance will be lost in the event of a disruption.
Other elements in the system come into play. Being prepared for a disruption means making sure those elements are working. The better they are set up the more likely you will keep balance in the system.
The system diagram has been simplified and there are other aspects that can affect the balance but this shows those that are relatively easy to deal with. It provides us with concrete actions we can take to prepare ourselves for the worst. It tells us what a handrail should look like.
Ensure processes are well designed
Although a well designed process is only part of the story it is the essential foundation.
Are the processes designed to deliver the outcome you expect?
Do those outcomes align with business objectives?
Is it feasible to deliver that outcome with the resources you have?
Do your systems and tools support the process?
Ensure processes are easy to understand
A well designed process needs to be easy to follow. Having your front line staff poring over abstract architectural diagrams, or detailed text based procedure, during a time of crisis is hardly going to make things easier.
Can the process be easily read by your front line staff?
Have you tested these with a broad sample of employees?
Are they unambiguous?
Do they provide enough flexibility for employees to make their own decisions?
Are they kept up-to-date?
Ensure processes are easy to find
Just like the handrail, processes need to be easy to find so that staff can reach out and grab them easily in times of crisis.
How do employees access the processes?
Are they easy to find?
Have you tested that using User Experience (UX) tools?
Do you run regular ‘safety demonstrations’ to help employees remember how it works?
Ensure processes are easy to maintain
If processes are difficult to update then the cost of doing so will quickly become prohibitive.
Do you have a system that makes it easy to update?
Are processes stored in a single place?
Does the process documentation have appropriate governance? (not too much or too little)
Need help with your processes? We can provide a review of your current process documentation based on the above criteria to see how well prepared you are to deal with the next disruptive event. Contact [email protected] for more information. Want to learn more about customer journeys? Check out Instrktiv.
While not the very first prototype you can see one of the first uses of the what and why boxes. The product was then called Score with a C. All the main controls are there which allowed us to start testing with real users before we officially released.
Our first official release of Skore was for the desktop only. The interface was simple, there was no way to apply styles to the content. The editor tool bar was along the top of the application rather than the left bar we use now. By this time we had added the sticky note feature that allowed the user to annotate process models.
Following a business review with the 
Back in late January we released our Unity interface, or Skore version 3, which brings all parts of the application into a single design. This version of the interface has undergone the most extensive user testing to date. This led to a standardisation of common functions such as Search, New, Edit and Save across each type of content in the workspace.
