In BPM and process improvement the motto is, don’t make just any change, make the right change. How do you select just the right initiative? When you’re starting a BPM journey, you want to get this right – you need the Goldilocks project!
I’m sure you’ve seen it before, as I have:- organisations who make large investments, only to find themselves months or years later not delivering – that’s a scary reality that keeps happening.
But how do you avoid those same mistakes? You want your project to be successful; you want to deliver real results that’ll make things better than they were before. Here’s where I parade out those over-used terms “low hanging fruit”, “pick your battles”, “don’t boil the ocean”. Fear not – that’s my parading over.
Anyway you look at it, unless you have been given a bottomless budget & zero timeframes for success (yeah right) these are the keys to getting it right:
- Have a senior stakeholder as a sponsor – they’ll set real measurable objectives, help you identify strategic selling points and be your PR manager within the business.
- Tie your project to a strategic goal to gain & keep senior management support.
- Start small & work towards bigger. Select strategically and take no longer than 4 months to finish & see rewards.
- Involve the right business functions. The more diversity you have in team membership, the more diverse your teams’ solutions.
Selecting the right project to begin your process improvement journey is crucial…just like that bed that was “just right” for Goldilocks. ‘Til next time – T.
One of the questions people ask me before I start a project, is how do you make BPM stick? How do you engage the staff and make sure that improved process is followed?
Well, there are lots of different ways. I could be glib & say with a big stick, but the flip side to the stick is always the carrot. Or as one of my team members used to tell me…”you catch more bees with honey” – she put on the best morning teas at meetings…but again, I digress.
Have you ever noticed that people hate being told what to do? But if they design a workaround or a change, they certainly stick to that like glue. I’ve found that the best way to get people to accept a new process is to get them involved in building it. They’re far more inclined to follow something they’ve had a hand in building and then slowly improve it over time, than they are if it’s enforced on them. So get teams involved.
Now, speaking of honey…we humans are a funny lot…a healthy dose of competition has a way of driving us and we do like our carrots (or honey). In process management speak, metrics become important to process stickability – what gets measured, gets improved.
Making process activity visible is the key, so teams can see how they are tracking, then they can self manage & prioritise work. Certainly, have the team leader monitor things to make sure cherry picking isn’t an issue and have escalations built in.
Teams with the ability to self manage perform really well. Encourage this with rewards – everyone likes rewards! They can be either small incentives during the year or by performance bonuses at the end of the year. Select the reward mechanism that suits your environment – I’ve seen some choose to do both!
Another way to help things stick – put a feedback mechanism in place. You’ll want to know if there are issues with a process that can be easily fixed – those doing the process will know what doesn’t work & how to fix it. Team members also like to know that their feedback would be welcome. Its a great way of weaving process stewardship.
So in summary, to make it stick:
#1 Have the teams involved up front;
#2 Metrics & rewards;
#3 Build a feedback mechanism.
The easiest way to manage all the alerts & metrics, including dashboard visibility is by implementing your processes in a BPMS – even if at first, there’s more people driven processing than system automated or integration activity.
Why do that, you ask?
There are immediate benefits like consistency in process, visibility of process, metrics are available at a glance & you’ve got real process data to support any business decisions.
Remember, when all is said and done, people either make or break a process – ignore the people aspect of change at your peril. If all else fails, emulate Theodore Roosevelt: “speak softly & carry a big stick”. ‘Til next time – T
Back in the ‘90s, I was involved in a large transformation program. It was back then I started in my process improvement journey.
I was working at a large Insurer and working with business people in their area of expertise. The SMEs (that was the first time I’d heard that term), my colleague and I, captured their processes…from memory I think it was processing a motor vehicle claim.
Anyway, we interviewed lots of people, made notes and ran away to model their process – we were using ABC Flow charter and produced a pretty messy looking process flow on this massive piece of paper. Surprisingly, it was really helpful and while modelling it seemed tedious – some of the SMEs got aggravated when we went over & over things – at the end we all had a really clear picture of what the process was like & how complicated it had become over the years.
I remember at a presentation of the captured flow, some of the team sitting back looking at it and they started nudging each other, saying “see…I really am busy when you keep hassling me for stuff”. That moment was gold! I never truly understood until that point WHY it was a good idea to model how things really got done. And today the same whys & how-to’s exist.
There’s is a lot of BPM software around – things have come a long way from the humble beginnings of buying ABC Flow charter on a floppy disc (yes I’m THAT old!). It’s a really confusing market out there & some of the claims made by vendors are really amazing. So which tool do you choose? Don’t always assume that the bigger (most expensive) hammer is the best choice – pick the right tool for your situation.
Do your homework – the trick is to know what you want a business process modeling tool for and how you will use it, before you go anywhere near purchasing. If I could advise anything, it would be that.
Nowadays there are also quick & savvy ways to lower your cost outlay, but still get really great software at a fraction of the price – while Software as a Service (SaaS) may have once seemed risky, today it’s a great way to start, with tools available at a fraction of the cost of some of the big guns.
Take a look at them – they might just be what you’re looking for.
The latest Jenkins newsletter, Continuous Information, has just been released. Its a great source for All Things Jenkins. To check it out, visit this link
Why not subscribe to the newsletters here
Or you can keep visiting our Blog – you never know what else you might find!
Centrum Systems will be sponsering Agile Australia 2011.
Agile Australia is going to be packed with case-studies of how leading businesses are adopting an Agile approach to stay ahead! As well as Agile dignitaries Alistair Cockburn and Martin Fowler, international Agile guru Jean Tabaka, and celebrated Australian industry author Rob Thomsett
- Learn how to respond quickly to change, minimise overall risk, improve quality, and enhance project outcomes
- Discover compelling examples of innovation and business value achieved through Agile
Please come to our stand and say hello…
There are many reasons and excuses why some applications are untested by automated tests, or at least not very tested. It could be an older application, the application might have been hard to test, or people writing it simply did not have the habit of writing automated tests. Having said that, most of us either inherited or created an untested mess at one point or another. This article attempts to explore techniques about increasing code coverage for such projects.
Say we set a goal of 80% test coverage and fail builds if they don’t meet that threshold. It is naturally quite feasible to meet this goal with every new check-in. Thus it is much easier set and enforce these kind of code coverage targets on new projects rather than on older, untested ones. It would be very disruptive to expect and enforce 80% code coverage on a project that is 5% tested straight away. A more gradual approach is necessary.
Revisiting the case of an older untested project, lets see how we can work towards gradually increasing code coverage. When working with an existing project, the only thing developers can claim is that new code will be tested. Luckily, this claim can also be enforced by using tools like Clover and its history threshold. The history threshold can be used to enforce that coverage is not decreasing, meaning that if new code is added to the application, it needs to be covered by tests. This practice can be beneficial in building a culture of automated testing while increasing code coverage for an application. Eventually, if efforts are taken to increase code coverage for the rest of the application, an absolute threshold can be instated to control that coverage does not fall below a certain acceptable level.
Testing can be disruptive
While we are fervent practitioners of automated testing and test driven development, we do recognise that in some situations, creating test for each line of code can be a bit disruptive. Naturally, throwaway proof of concepts don’t need the same strict level of code coverage as applications that will need maintenance. Furthermore, it is not trivial to work with and test code using frameworks, tools or languages unfamiliar to the team. There are also frameworks that are not easily testable. But as a team learns know to write automated tests effectively, the technique described above can be applied to make up for the initial looseness.
Finally, while all code should be checked by automated tests, we find that this is not always the case. Many reasons lead to untested code, but there are tools and techniques like Clover’s history threshold that can put a project back on track in a controlled and steady fashion. When a situation is bad, we can at least ensure that we are making it better, rather than adding to the problem.