29 March 2011
Designing process for other people
Posted by
Craig Brown
I've been involved in process analysis and design for ages. First in my local workspace, then in my team space, my department and then they let me wild with a whole business unit. I did things that, on the whole made sense, but occasionally scared the pants off some of my stakeholders. Luckily, things have mostly worked out.
In my wake I have seen problems though. Finding the balance between back office process gnomes like me and putting control of how work is to be managed in the hands of those that do the work is not a simple black and white exercise.
At the very least there is the change management aspect of telling someone to change the way they think and act when they come to work. Don't forget that a new process changes the underlying values that underpin the purpose of the work.
Then there is depth of knowledge and unexpected consequences. When you re-organize the way teams work, you are certain, upon a follow up visit to see how things went to discover various interpretations, partial adoption of the change and occasionally outright bizarre scenarios that just weren't anticipated.
Lastly there is the insidious undermining of the authority and decision making rights of the staff who do the work. You take away their ownership of how things get done, you take away a good deal of commitment to outcomes and replace it with commitment to process compliance.
This last scenario has been flogged to death recently in the context of managing project teams, but the truth is it's a very easy thing to see in many more places than project teams. Just go to any call centre, or back office processing team and there it is. It wasn't always like that and it doesn't have to be like that today.
When changing business processes involve the people who do the work and help them feel like they are in control of what is happening. When designing new processes, ensure that they are defined sufficiently loosely to allow a range of responses to the many and varies customer needs and wants they are going to come across.
Subscribe to:
Post Comments (Atom)
Popular Posts
-
I have been having a bit of a discussion over at the IIBA blog with Kevin (VP BOK) and Julian (Chief architect.) It’s migrated over to ...
-
Due to popular demand I have aggregated some information on User Stories and created a simple template. If you feel this would be useful to...
-
Better Projects Templates I am uploading a couple of project document templates to Google Docs. As I add more I'll post them up here. You...
-
You've heard many reasons why project fail. Here is a discussion hosted by BCS on why projects work. The discussion covers four dimensio...
-
The Precedence Diagramming Method ( PDM ) was developed in the early 1960s by H.B. Zachry in cooperation with IBM. It has largely repla...
-
In the below video some of the #10yrsagile participants discuss the role of the Business Analyst. A question for you; Do you agree or di...
-
This is a guest post by Jeff Hobbs. Jeff is a project manager at ActiveState Software who provide pm and collaboration software. Email, ...
-
In one of the Carnivals of Business Analysts the theme was “ Requirements Analysis ." I searched the web far and wide and came up with a n...
-
The definition of a stakeholder is controversial. For example, project team members are generally not considered stakeholders, but in virtua...
-
I have written about the V-Model across several posts. The V model is a testing focused expansion of the software development lifecycle. In ...

0 comments:
Post a Comment