Thoughts

Open Source Project Management Software

Alan — Tue, 18 Nov 2008 11:24:34 +0000

The industry standard is Microsoft's Project, a few years ago, Project Managers Workbench was also a contender. It still may be but I haven't seen it in use for a while.

Neither are open-source.

Serena's OpenProj fills this gap nicely (it was run by Projity until Serena's recent acquisition of Projity). It works on Mac OS X (10.4 here, but can't see any reason it wouldn't work on 10.5 either)

OpenProj

OpenProj is the more feature-rich than most open-source project manager appications, with a number features that you'd find in MS Project. As with most open-source products, it's a bit quirky, but don't let that put you off. Spend 5 minutes with this product and you should get the hang of it. Gantt charts are easy to add, including dragging to implement dependencies between tasks.

Some of the interface seems odd, I'm not sure how much of that is that I'm on a MacBook (so no actual second mouse button although that's usually easy to emulate with holding ⌘. I found it awkward to delete tasks and dependencies (links). This was infuriating as I was learning which way dragging dependencies worked. Work it out first and it's nice and easy after that.

Having a screen split into different, but related panes is becoming common-place nowadays. OpenProj handles this well (better than MS Project in my opinion since it provides standard screen layouts by default. One example is the Gantt chart and spreadsheet in the top half with a resource histogram in the bottom-half. Very useful. Unfortunately, the resource histogram seems to have some odd behaviour. I tested it with 2 resources (Alan and Not Alan). For some reason, Not Alan has a lot more capacity for work than Alan. Maybe it knows something...

Looking at the resource forms showed no differences between the two. So I'm confused. It could just be an auto-zoom feature where the histogram is zoomed to fit the space available. That would be ok given two features which OpenProj doesn't have:

Values on the axes - is the scale always the same?
Manual zoom and fixed zoom, so that the same distance on the screen always shows the same allocation of resource.

So right now, I'm confused as to how useful that part of it is. Maybe I'll look into it in more detail in future.

As with any Gantt/Project Management tool, learn the difference between fixed duration, fixed resource and fixed work. Fortunately OpenProj can handle all three, making life a lot easier, although I'm not sure if the default can be changed away from fixed duration.

Want more?

There's an interesting business model behind OpenProj. It's based on the popular concept of offering a standard package for free, then charging for additional features. The difference to most is that the standard will suffice for the vast majority of users. I like that. The extensions that require charging for allow you to host the projects with Projity, reporting and progress reporting. Perhaps more important is the extension allowing users to link projects together.

For Windows Users

I've never used it, but Open Workbench looks good for users on Windows.

Other Options

GanttProject is another OS X compatible open-source application. It's much simpler than OpenProj, but does have the advantages of the application being completely open-source, i.e. no commercial add-ons or services. Overall, I found it limited to the point that I didn't feel it worth writing more than a paragraph on. The only reason I could see why a user would use GanttProject instead of OpenProj is if they want protection from whatever the owning company is doing with it. And choosing GanttProject may not be more of a guarantee either.

Issues with Process Mapping

Alan — Wed, 30 Jul 2008 18:50:32 +0000

I've been using process mapping for over a decade now. I've probably been the recipient of more process maps than I've created, as I've had to implement changes that have already been designed by others. I've also had to talk many business users through the intricacies of their redesigned processes, especially if they (wrongly) hadn't been designed by them. The most common scenario for me is where I'm asked to review process maps and assess how easily they could be implemented, bringing together knowledge of people, processes and IT/ICT.

Over that time, I've seen many sides for and against process mapping. I'll discuss some of the issues and some of the methods for mitigating the risks associated with mapping processes.

1. Takes too much time

Mapping a process takes a long time. If that's the only method that's being used, then it will take longer than you expect. The only exception is that if you've been through similar exercises before, then you should already have some idea of how long it can take. To get a high level map is easy, to get to sufficient detail that a reader can understand the process takes a lot more time. This is time is extended if there is interaction with IT systems and different locations.

2. No standards

Some people map processes for a living. Worth bearing that in mind if you're new to it. You can generally tell how much relevant experience a person has by looking at their output and any comments they attach to it. Have they picked a standard notation? Do all the decision points have two or more outputs? Are decisions labelled differently to process steps? And so on. Whatever the standard, a process map should be internally consistent. If a decision is a shaped as a diamond in one part of a map, then all decisions should be diamonds.

3. Conflicting standards

Assuming that the process-map author used a standard, it often doesn't conform to the standard that the rest of the team are meant to be working with. The level of rigour required - as driven by an evaluation of potential risk - determines how closely diagrams have to conform to the standard. Some deviation is often permissible, and may even introduce new ideas, just bear in mind that a process map is a communication tool. The more standards people have to learn, the less concise and the less effective the tool becomes in communicating.

4. Not enough detail

The most common issue I see is that I receive just a process map. There has to be more information. The process map is a diagram of the process, but it isn't the process itself, nor is it a complete description of the process. It is one tool for communication, there are others and analysts should some of these should be used. For instance, there should be a process description supporting the process map. This would provide the detail of each process step, providing elements that couldn't be included in the diagram. Remember that a process map is a diagram and you'll often need words to describe the process more completely. Words or pictures alone are often not sufficient, the combination of the two together work really well.

5. Too much detail

Better too much detail than too little. I'm always curious if there's such a thing as too much detail in process maps since the aim is to capture everything so that it can be understood, replicated, changed and/or implemented.

My current answer to this is "yes". Once you're into the realm of mapping something that's rarely done, has very little associated risk and you know you're going to change it, then you don't need much detail.

You also don't need much detail if you're just trying to scope out the activities of an organisation.

Another indication of too much detail is when an analyst has focussed on one area more than another such that most maps are high level and one is too detailed in comparison. So unless there's reason to concentrate on that one area such as you know you're going to be doing that in the following stage, I'd start to think that there's too much relative detail.

6. Users don't understand them

Process maps should be easy for users to understand. If they're not, then question the standard; are you using the most appropriate standard? For instance, I noticed that early versions of UML Activity Diagrams confused users due to the diagonal lines making the sequence of events unclear. Many of those Activity Diagrams still included horizontal and vertical lines, but the standard permitted diagonals. Compare that to later versions of the Activity Diagrams. Now, I've no idea if it's the standard or just best practice that means that most lines are horizontal or vertical, but either way, I've seen a change towards that practice.

It is also worth taking a key or legend with you or at least explaining it in person. Mention what a process step is, what a terminator is, what a gateway is and how to read them. Especially talk through the difference between parallel and sequential processes.

7. Users aren't involved with them

This is stake-holder management. By and large, people resist change. Not involving users in the process mapping exercise increases the risk of resistance and increases inaccuracy. The fewer users, the greater the risk. Fortunately, it's rarer nowadays to see the creation of process maps not involving any users. But take it a step further, instead of a review process, move some of the ownership or responsibility onto the users. That doesn't mean that they should be responsible for creating the maps, but that they should be happy with their content and happy that they represent what they do.

8. Don't have the tools

You can't do process maps well in MS Powerpoint. You can get so far and do a very high-level sketch, but you can capture detail that way. Trying to results in a mess, a divergence from standards and a confused user.

At worst, use MS Visio. This should be the lowest level of IT tool you should use. Better still, find a purpose-built tool. Make sure you can export into a format that your audience can open and read. Test the export and read process a few times. Visio used to be a bit unpredictable in its export output, but that seems to have settled down a lot. All depends what version you're using and what the diagram includes.

If you're a bit old-school and use post-its on brown-paper. Tape the post-its down once the process is agreed.

Improving Customer Acceptance

Alan — Thu, 10 Jul 2008 19:00:15 +0000

Client Acceptance is a key issue for me across every sector I work in. A formal acceptance process can mitigate many issues to the point that problems are caught earlier and hence, projects delayed less.

Mix Formality and Informality

Most project frameworks incorporate a formal model for customer approval. This is fine in that it lets both parties know what to expect at the time of review. However if followed to the letter, it can result in the client being out of the loop on how the product is developing until the point they get to test it.

The best way I've found is to have a formal approach running in parallel with an informal approach.

The formal approach has the process laid out for review and approval, the informal approach lends to giving the client early sight of the product in an unfinished state. The latter only works when the client has the trust in the supplier to finish the job to the required quality. If not, then don't supply unfinished work because that is often the level that the client comes to expect and they may go elsewhere.

The Process

Every product (could be a song, a mix, a master, an image, a document) should undergo a Client Acceptance process. This could also be called a Sign-off Procedure, Customer Approval process, etc.

The usual route is to submit the product to the client for review. The client's responsibility is to review the product with the overall result being:

Accepted, no changes required - client to sign that version
Accepted, minor changes required, changes are agreed at that meeting, client to sign version agreeing to changes, no need to resubmit product for review
Rejected, changes required, resubmit for review

And this process keeps going round and round until the client's happy.

Improve the Process

I mentioned earlier that the informal approach of letting the client view the product in an early state can be beneficial to both parties. This works well if the client is taken on the journey of the product development. That's my preferred way of working. From the point that the client commissions the work, they are involved. It has the implication that the client has to spare time and personnel on a regular and frequent basis. They'll learn what's involved and many clients initially resist the effort that they have to put in to be involved to this level. It depends on the client and their needs.

Next?

I'll follow this up discussing the typical signs of client's being unreasonable at the customer approval stage.

Mind Map of Collaboration

Alan — Wed, 25 Jun 2008 19:17:07 +0000

I posted a long article broken into 4 parts providing 43 reasons for collaboration in musical activities. Perhaps more interesting is how I ended up with the finished article.

Background

I write my articles in Ecto. It's good for what I want to do with it, helping me write the words of the articles, but it's not much use as a tool for creating articles. What's missing is anything that helps organising thoughts. Fortunately, most new Macs come with a version of OmniOutliner which is a good tool for the job. You could also use the slide feature of MS Powerpoint or OpenOffice/NeoOffice.

This was at a point when I was quickly using up my ideas for articles and had to generate some new ideas before I ran out. I try to keep at least 5 articles ahead of what I'm posting, all in various stages of completion.

At times like these, I revert to mind-mapping and usually with a piece of paper, although a few software tools do come close. There's something better about pen and paper that works well for me.

Creativity

I didn't have my laptop with me, but I did have a small pad I carry most places. It's A5 spiral bound, so half the size of an A4. That made for a challenge for doing mindmaps. I started with what I wanted to focus on in the middle, so I wrote the word "Creativity" and drew a circle around it. Using that as a hub, I wrote out some other words on the spokes and then used them as hubs to generate more ideas or more detail. One of the words was collaboration. That became it's own mindmap. So I started again with Collaboration at the centre. The rest is what you see on the scanned image that's attached below.

Logical

I find mind-maps to be great tools. I like how concepts relate to other concepts. They suit my organised mind as I can see all the relationships at a quick glance. My mind-maps tend to have an inherent logical structure, possibly because I've got a good grounding in logical data model from database design. Mind-maps can have a similar inherent logical structure, but are often visually messier since they're a good way of capturing thoughts as they occur.

Workshops

I've found mindmaps to be highly effective in capturing what a group of people are thinking. Write the central concept down and ask for thoughts. You may need a parking area to capture non-related ideas. The trick is to understand whether the item is truly non-related, it may just need another hub to connect it properly. Take a hub and explore each of the spokes in turn, capture other ideas as they arise. Then make each of the spokes into a hub and explore them.

Further Reading

For a good introduction to mind maps, try the books by Tony Buzan.

Opensource Software

Unfortunately, I've never found a complete open source application for mind-maps. Some of them are useful, but my impression is always that it's better to use paper or flipchart first, then just a diagramming tool afterwards. Alternatively, look at commercial software.

FreeMind - best standard "free" software for mind-mapping, still a bit word- and phrase-based for me. Not quite visual enough

NeoOffice - was the port of OpenOffice to native OS X - has a presentation and diagramming tool

OpenOffice - several platforms, now native beta for OS X

Landscape or Portrait?

The general recommendation is to turn the pad so that the pad is in landscape as opposed to the traditional portrait. It's a good idea, but I've always had issues with writing across lines the wrong way. Just not neat enough! It's a case of blank paper would be better than lined paper.

Progress Update

Alan — Sun, 01 Jun 2008 14:23:38 +0000

Wow, I knew I've been busy on other tasks for a week or so, but I hadn't realised it had been over 4 weeks since my last post. That's the first time I've had a gap of this size since I started out with this site.

Screening

One of the projects I'm involved in had a screening of its pilot episode in the main cinema complex in Manchester last week. Unlike other projects where I'd had more control of the timing and placement of audio, this was a project where I had only provided musical intro, outro, stings and a few themes, and some of that was in collaboration with another musician. I was interested to see how the director had chosen to place the music in the episode, how it had been mixed (e.g. forward or placed back in the mix) and I was also interested in watching the episode. Up until that point, I hadn't seen the episode.

Business Change, Process Mapping and BPR

I'm working on a long-term transformation project at the moment. As I'm doing so, I'm keeping an eye out for the common pitfalls of process mapping. I don't think there's much I want to change in the process-mapping series, what I've already written is still valid. There are a few points that I think could make it easier to understand. Plus I want to continue the series, it's only a few articles long so far and there's so much more to write. One of the main points I'll discuss is the time it takes to do full As-Is and To-Be models and how other tools and processes such as those found in Lean can be more beneficial, depending on the context.

This is actually the reason why there hasn't been much other activity on this site. The demands of a full-time client plus travel there and back is leaving little time for the updating. It does however leave me with time to write, just not time to research and upload the texts.

So what now?

The good side is that I've been writing some articles off-line for the musical creativity series. I'll publish those soon. Some will take longer than others as it will take time to prepare samples.

Status of the Musical Instrument Retail Industry

I've been watching the failure of Sound Control/Turnkey/Soho Soundhouse with interest. Over the last few years, I'd only buy from one or two named individuals in that chain to the point that I'd drive past 2 of my local shops and purchase from the shop in another city a couple of hours away for better service. Add to that the fact that the sales stock was getting progressively more budget-based for the items I'd want to buy meant that I was looking around for a better store.

New Kit

The failure of Sound Control comes at an odd time. I am looking for a new hardware compressor to complement what I already use. Sound Control didn't really sell much pro outboard beyond the SSL range, so I was already wondering how to broach this with them or to branch off to other companies such as KMR.

Indie Filmmaking

venn is still progressing. Shooting was completed a couple of weeks ago for a few scenes. Means I should have some rough edits to write to soon.

Space Opera

I've also watched a few independent sci-fi projects collapse over the last month or so. One or two appear to have collapsed outright, others have been delayed as the respective teams understand more about what's involved

Stuffed

My own short-movie project, Stuffed, is on hold while I think about what background I want. When I started out with Stuffed, I wasn't thinking about the background. That's not an oversight, just that I hadn't noticed the opportunity. One day I was looking at the footage and the idea hit me. I've had a few short attempts using Public Domain footage from archive.org but that hasn't proved sufficient quality. I'm not on the look-out for a good background which will convert well to PAL-I resolution - this isn't a HD project. I'd like to get it finished soon.

The 2nd Twenty Features of a Space Opera: 21-40

Alan — Thu, 20 Mar 2008 13:18:26 +0000

This is the second part of the list, part 1 is in an earlier article.

21. There's always someone else
The good guys kill the evil overlord and/or dismantle the evil operation. If a sequel is required, then the following are the usual results:

The overlord is not truly dead. He regenerates and returns with more force for the sequel
The overlord has an heir or a lieutenant to take up the fight
There's a newer, bigger and badder evil to fight next time
The ex-overlord's romantic involvement wants revenge

22. Big spaceships have different armour
If the big spaceship is on the good side, then even the most powerful weapons will only scratch the surface unless the battle is near the end of a series.

If the big spaceship is on the evil side, then a small ship can destroy the larger ship by aiming at more vulnerable areas.

23. Evil spaceships have lousy weapons-targeting systems
An extension of (22), evil spaceships are unable to target the vulnerable areas of good ships with their weapons. Just seems to be the way of things.

24. In space, there's an up and down
Proof: Spaceships always fight the same way up. Ok, it's wrong, but that's the way that it's shown in movies and tv. Why though? I can cope with the fact that unless there's something closeby to orient against, then there's no up or down. So why don't we see ships attacking "upside down" from "underneath" the target ship?

25. Oil and non-stick coatings don't exist anymore
Doors open noisily rather than silently on their tracks. Even those that operate by an expanding iris make a noise as the iris opens.

26. Idiotic Minions
The evil organisation consists of an intelligent, but sometimes deluded, overlord presiding over a cast of mindless idiots. There will be a few intelligent underlings in the midst of the organisation, but on the whole, they are overwhelmed by the order-following nature of the rest of the organisation.

27. Spaceships hum
Possibly in more ways than one.

Whatever the spaceship, there's a background noise. I think it's meant to be hum of the engine, but in some ships the engine's almost a mile away from the bridge. I'd hate to be in the crew quarters closer to the engine if it makes that much noise from a mile away.

28. Windscreen at the point of greatest friction
I take no credit whatsoever for this one, but unfortunately I've no idea where it was first mentioned. I've known about it since before 1990. Anyway, to the point. The spaceships will have transparent windscreens at the front of the plane where they're most likely to encounter the greatest force, e.g. from friction on re-entry. Think about NASA Space Shuttles, the nose of the vehicle is covered with ceramic tiles. The windscreen sits on top of the nose and is itself shielded by the tiles of the nose. Few ships in Space Operas have much physical shielding. From what I remember, the 1960s Star Trek Enterprise had a display screen rather than a window.

29. Forcefields and energy shield
A potential corollary of (28), every spacecraft has a shield. Not only do they have shields, but the shields have levels and can be depleted and recharged.

30. Shields are independent of weapons
This may not seem a major point but it's an interesting one for me. I can't see why engineers would design and build a ship whose shields collapse before the weapons do. I'd have thought that shields were more critical than weapons, especially as there's more need for shields when there are no enemies, even asteroids can puncture hulls. So if they're more critical, why do they deplete first?

Wouldn't the same energy source power both shields and energy weapons? So why does one break before the other? In that case, you'd think that both would stop working at the same time. Or is it that the designers put the control systems or power conduits for the shields in more vulnerable areas than weapons? I believe a rethink is in order.

31. The best pilot can still fly while blinded
If the best pilot is blinded, that will not stop him/her from piloting the spaceships. Instead they will feel their way towards the destination.

32. Slavery results in interest in technology
Usually, the vastly different levels of technology will not be of interest to anyone on the planet, unless they have been enslaved. This triggers a switch in them and the only way to escape slavery is to obtain the advanced technology.

33. People are less bothered by the little things in life
Wouldn't the noisy doors annoy you to pieces? Every door would have a dent from my boot or lie smouldering from a blast. That noise would drive me up the wall. Same goes for the announcement of a ship-wide or fleet-wide message. It's worse than the introductory ident you get in a supermarket, just before the announcer tells you about a special offer that no-one is interested in.

34. Virus
Enemies can attack electronically using a computer virus. This can affect any and every ship in a fleet, despite there being many different models of ship (and you'd assume many different flight computers, lifesupport systems, weapons systems, etc). Yet we still see a virus capable of disabling all ships in a fleet, without exception.

35. Odd Value of Goods
There's an immense cost to owning a spaceship, the fuels to supply it and the crew to run it, let alone bribes, official registrations, etc. However, the bartering value of fuel supplies, food supplies and weapons just doesn't add up. After all, how much wheat grain does a ship cost? And if the fuel supply is such a rare substance that the crew cannot find it when they're in space apart from on certain planets, then how can a stable economy that includes agriculture exist?

I can see how agriculture is a necessity in providing food for life, but I can't see how a trader could make a profit transporting a normal crop from one planet to another. The cost of that crop would be vastly overrated on the target planet to make it worth it? And if so, why would people settle there, unless they had their own product/service that could be sold at an incredibly high price? Hmm, brings back memories of Elite.

36. Evil ships can hide, good ships cannot
An evil ship can hide on the far side of a planet, moon or sun, despite the powerful sensors available to both fleets. It will remain hidden until its captain decides to attack the good ships. A good ship can hide only for a limited time until found by an enemy recon squadron. If lucky, the scouts can be destroyed before the signal back to the evil ship. The limited time allows for a small breather, a few comedy moments and a pause before the next fight or flight sequence.

37. Evil is evil
There doesn't need to be a reason for evil, it just is. There doesn't need to be a reason for planetary invasion or galactic domination, it's just part of the overlord's plan. Occasionally, there's a rationale behind it, but it hardly makes sense other than obtaining absolute power. It seems that the invasion comes first, the motive second in the eyes of the screenwriters. Whereas, even in the eyes of the evil characters, the rationale would come first and the invasion second.

38. Under-Society
Humans are more "perfect" than they ever were. There exists an under-society of humans who didn't benefit from/weren't subjected to the medical or gene therapies that apply to the rest of mankind. These are only displayed when we are to see:

how generous the good captain is
how evil the evil captain is
how humans of all status are worth more than enemies
the rebels in the under-society overthrow their evil enslavers

39. Instant Communications
Radio communications work on the first attempt between ships owned by different races. Shouldn't there be some boot-strapping to get the two communications systems being able to talk to each other? Think about it, often they've never contacted each other before so all the protocols would be new and there's no guarantee that both races would implement systems using the same technology.

40. Humans are average
There are aliens, even those that can be played by actors without any additional make-up, that are stronger than humans as well as those than are weaker. Some are more intelligent, some less. Some more technologically advanced, some less. And so on for every measure, humans sit in the middle. It is the strength of being average that makes humans strong and able to succeed. Two things about this that I don't agree with:

Wouldn't a crew comprised of several other races succeed better by combining the strengths of each race? Even the original Star Trek included an alien to assist them.
Wouldn't humans be at the top of one scale or the bottom of another? Is it possible to be just at the top of one scale, that of averageness?

Plot Devices and Flaws
As I was writing this, I noticed that some were plot devices for episodes or flaws in Space Operas in general. I've removed most of them out and I'll publish them separately in later articles.

This is part of the Space Opera Side Project.

Introducing Sub-Processes - Fundamentals of Process Mapping

Alan — Tue, 04 Mar 2008 12:24:40 +0000

Introduction

Processes can be broken down into more detailed processes. In this article, I'll take one of the process steps from the previous article and look in more detail about how it connects to the other components of the process.

Some Perspective

A key feature of any workflow system is that you should be able to look at the system from different levels, e.g. a director's view of the system may only show 5 or so process steps and cover what it takes 10-200 people or more to perform. A user's workflow will probably require several process maps, each relating to the different processes that they perform on a daily basis and some that are less frequent. The solution's workflow could feature many process maps, perhaps describing the user interfaces and the core system's interfaces with external solutions.

Each map communicates to its intended audience. That means that we, as analysts, have to write for that audience. Fortunately they all follow the same basic principles. They should all relate to each other, if they don't, then there's a gap that needs to be addressed.

Using the 3 levels above, we should be able to look at the director's level process model and delve into the process steps. Say we look at the process step 1 in that model, we should be able to find a user-level process model that shows us the detail of that step. Similary when looking at the user-level process model, we should be able to look any process step and see more detail in the process described in the solution workflow.

So how do the processes fit together?

The first point to understand is that most process steps can be a processes in their own right, usually with more detail. Rather than have all that detail on every diagram, it's more common to display a box for the process step and that refers to a more detailed process map for that step.

Let's take the Buy a Book process from the previous example and work through that.

The Pay For Book process step includes a number of its own steps when it's viewed as a process. We'll take a very simple concept of paying by cash. The same principles apply to paying by credit card, just that there's more involved in that process.

Like all of these processes, real-life is more complex. For instance, scanning the book would display the price on the till. There's also more happening with process cash payment, e.g. what about giving change back? I've changed to yellow just so it's easier to show the different levels in the following diagram.

The glue is the Process Start and Process End points. These connect to other processes.

Note the name of the Process Start? It's the same text as the process step in the original Buy A Book process. When reading Buy a Book, you may want more detail about Pay for Book, so look for the process model entitled Pay For Book and it should have one Process Start with the same name. The End point again assumes that the process has been completed. If we were looking at more detail, it could be that the buyer couldn't pay and so didn't purchase a book. For the moment, we'll leave that outcome.

If you look at the Pay for Book process-step in the top row of the above image, you'll notice I've included a small image of the Pay for Book process. The use of colours is just to help me show how the processes fit together here. It's incredibly rare to have the process and the more detailed process on the same page. In fact, I can't ever remember doing that apart from when I'm showing the relationships between processes in articles such as this one.

I mentioned that the Process Starts and Process Ends are the glue because the detailed process (the lower one in the above diagram) should be able to fit into the main process (the upper one in the above diagram). It should do this without overlapping into any other process steps. Choose Book will also have its own detailed process map.

Here's an incorrect example highlighting Choose Book and Pay For Book.

That Choose Book process relates to the Choose Book process step. Actually, maybe I should state that the Choose Book process is the Choose Book process step. It's the same thing, just different views of it. One view shows more detail than the other. 

In the above diagram, I've put two crosses, not part of any standard. I've used them to highlight what's wrong with the Choose Book process as depicted above. The second of the crosses is easiest to explain.

The process step of Scan Book more properly belongs in the Pay for Book process. We can see it in the Pay For Book process, so let's keep it there. If it's also in the Choose Book process, then we're duplicating actions. Someone following the overall process in the diagram above would end up scanning books twice. That's not right.

The cross on Take to Pay Desk is more awkward and shows where we cross the boundary between science and art. Does Take to Pay Desk belong more to selecting a book or paying for it? My view is that it should be in Pay for Book. Since the book is chosen at the point that the customer picks up the book. Anything after that (apart from putting it back in the bookrack again) is beyond the scope of choosing a book. Two other scenarios come to mind that reinforce the fact that it's in the wrong process above:

if they were going to steal the book, they wouldn't take it to Pay Desk.
if they were going to read the book in the store, as is getting a lot more common-place in the UK, they wouldn't need to take it to the Pay Desk.

In both the above scenarios, the process of Choose Book would still be relevant. In the second scenario, the customer would still have followed the Choose Book process.

I've simplified the diagram by removing the Take to Pay Desk and Scan Book process steps and inserting the Take to Pay Desk process step in the Pay for Book process.

Remember: you won't see the processes on the same page. That's just so I can present the relationships between them.

From what we have seen so far, we'd have 3 separate, but related process models. One for each of the following:

Buy a Book
Choose a Book
Pay for Book

Numbering the processes

Some of that was getting difficult to describe. The fact that Pay for Book is a process step in one diagram and a whole process was causing some difficulties in describing the relationship. I'd recommend reading through it again, slower this time, checking that you are certain which process step is being to referred to at each point.

Some standards help understanding by providing a key to each process step. The most common method is to assign a unique number to each process. The benefit of this is that you can define the process once (e.g. say we define "check stock level") and then we can use it elsewhere as a process step (e.g. in an ordering, logistics or auditing processes).

Some standards help you navigate the hierarchy by assigning and set of numbers, e.g. everything at the top level has one number (1, 2, 3, 99, 123, etc). The next level down would have another point number so that all the process steps in process 1 would have numbers of 1.1, 1.2, 1.3 and those in process 3 would have 3.1, 3.2. Down another level and we'd see labels such 1.1.1, 1.3.4 and 4.3.5. This does lean towards a parent-child relationship between processes. Not necessarily bad, but I prefer more freedom.

The more levels and the greater the complexity, the greater the need for a naming convention.

Reuse

By allowing processes to appear in other process maps, they can be reused. For instance, the Scan Book process step above could be used elsewhere, e.g. to retrieve information about a book such as how many are in stock, price, different versions, etc. The process step would be the same in all processes.

Common Mistakes

The Process Start in a subprocess doesn't relate to any process step in any other process map. So you'd never actually use this process.

The process overlaps with the previous or next process in the chain - as we saw earlier with the Scan Book process step.

The Process Ends (i.e. the outcomes of a process) for the subprocesses aren't reflected in the higher-level processes.

Change in process mapping methods - giving a process step to a different analyst can result in that process step being described using different methods or no standards. This isn't necessarily a mistake, but should be considered before responsibility for process mapping is delegated.

Why 3 Levels?

You don't have to have 3 levels, they suited the early part of this article. It's a common concept in a lot of domains. In Data-modelling, the hierarchy of Conceptual, Logical and Physical data models has long proved beneficial. Closer to the process domain, Alistair Cockburn was promoting multiple levels of Use Cases almost a decade ago.

When do you stop going smaller?

When everyone understands the process step without having to ask any questions.

For many clients, two levels is sufficient for the process analysts to be involved in; a high-level mapping of all the processes, then a more detailed view of each process. a 3rd level may be created for the more complex processes that require more analysis. Developers are likely to look for further detail, so either another level or different diagramming technique can be used.

Recap

A process step can be described in more detail in its own process map
Processes can be re-used in more than one process
Process maps should contain sufficient information to relate to each other - using the Process Starts and Process Ends
Different readers will have different ideas of how much detail they want to see
The different levels of process maps can be used for different audiences
As the number of processes and levels increases, the greater the need for a naming convention

Next Article

Notice that Buy a Book was written from the buyer's perspective whereas Pay For Book was written from the Bookseller's perspective. We'll discuss how to handle that in the next article.

Which Diagram type?

All the diagrams above could be process maps. In some cases, especially with mapping the flow of user-interfaces, then UML Sequence Diagrams can be more useful than Activity Diagrams. I'll explain why in a later article.

This is an article in the Fundamentals of Process Mapping online book provided by Award Sounds.

What does process mapping have to do with Music, Audio, Photography and Moviemaking?

Alan — Tue, 26 Feb 2008 15:49:53 +0000

The Short Answer

Everything

The Longer Answer

The longer answer is that every series of actions we perform can be thought of as a process. Understanding those processes will help us improve, even as individuals, whether we're concerned with Music, Audio, Photography, Moviemaking or what have you. I'll discuss each in turn and set the scene for forthcoming articles.

A Basic Process

Making a cup of tea is a process. It's a set of actions that have to be performed in sequence so that the end result, a cup of tea, is achieved. It's quite a complex process when you look at the detail and document it fully. But it's rare that it ever gets documented to that great a level. Occupational Therapists have a test for clients where they see if their client can make a cup of tea. Sometimes, the client forgets to heat the water, other times they forget to put the tea-bag (or other flavouring) in, or forget to put any water in and so on. The number of activities that we take for granted is astronomical yet we know by habit what the sequence of those activities is.

Every process can be mapped. It will take forever and may not be beneficial, but you can map any process. The trick is in deciding which processes to focus on.

Now back to the title, let's look at process mapping and the other facets of this website.

Music and Audio

Can you remember the first time that you compared your home-grown track against a commercial CD? It was quiet, probably very quiet. You may then have learned that you needed to get your tracks mastered. You may have also learned about dynamic compression and if you're still lucky, you treated it with awe as opposed to applying it everywhere and anywhere.

Mastering is a process. Some of the process steps are applying equalisation, manipulating stereo imaging, applying reverb and applying compression.

If you do this on the cheap at home rather than send tracks out to a mastering engineer, you're then into having to dither tracks yourself as well. Similar to the revelation you experienced with the quiet home-grown track, you'll have probably encountered that distortion resulting from when you reduce the bit-depth without dithering.

Where am I going with this?

There's a process in there. For every track, I follow the same process. Think about that. "For every track, I follow the same process."

If I can automate any tasks, I'll improve my situation greatly. Some of the benefits of automating regular tasks:

Save time
Reduce chance of error compared to manually performing the same tasks
Ability to process changes in batch
Ability to schedule changes
Ability to trigger changes based on events (e.g. inserting a card into a card reader)
Achieve consistency in results.

Learning

More important for me is that I can compare my process against that of others and learn from it. It may be that I learn I'm happier with my process than what others are doing, but at least I've decided on keeping my process. I'll go into that process in a bit more depth in a later article.

Music and Audio Recording

What are the steps to recording a track?

Choosing a suitable room, deciding where the musicians will stand, configuring portable acoustic treatments, laying out the microphones and cable, connecting to the recording equipment and so on. All fits into a process.

Look at most questions by recording newbies along the lines of "what's the best way of recording instrument x". They're looking for a description of the process, even though they may not know it. What the more advanced engineer knows is that the key to a lot of the questions is knowing the how the results from the basic processes sound and then figuring out a good solution from there. That solution may include changing the basic process to meet the client's artistic aims. The article on comparing how different pros recorded guitars provides great insight into this area (article is available to subscribers only at the time of writing this article, although I think it's released months after the publication date).

Photography

Digital Photography software is ripe with workflow. It's one of the few subject areas where I've really seen some real progress in workflow and implementing processes that can be used on a regular basis. Some make use of the operating system's specific automation features, e.g. OS X's automator andscript tools are great for this purpose.

Setting up a shoot is a process. Deciding on studio, lighting, props, models, camera bodies, lenses, positions, aperture, etc. All part of a process. On the other side, if you're hiring out studio space to photographers, you probably go through a process, including processing payment, booking and even the clear-up after the shoot. The more you know about your process, the more flexible you can be to client demands without undercharging them.

As a photographer, you shoot out in the field/on location, bring the images back to a computer. Do you:

Wrap-up

In the above text, there are a lot of questions. Largely rhetorical from my point of view. They're present to make us think about how we perform our activities. By analysing the process - or more plainly, just by thinking through the actions that we perform - we can improve how we work.

In the next few related articles, I'll pick up the specific topics and discuss them in more detail. I'll also publish my processes and workflows.

I've started a series on the Fundamentals of Process Mapping for a wider audience but still useful as background to this article.

Introducing Decision Points

Alan — Fri, 22 Feb 2008 09:11:04 +0000

In the previous article, I introduced a basic process map consisting of a process start point, a process end point, two process steps and connectors.

It's rare that a process map is a straight line like that simplified process. There are usually options which can take the process down different paths.

In the case of our book-buying process, we may want to ask the customer if they want the book gift-wrapped as part of free promotion.

Decision Points
The most common symbol for a decision point is a diamond (or a rhombus for the pedants out there). Similar to the process steps, the decision point is linked by a connector into the diamond. The difference is that the decision point should have at least two connectors coming out. It's generally best to label each connectors with the outcome that it represents, otherwise the reader is guessing which outcome they're looking at.

So back to the gift-wrap example.

As you can see, I've added the following items to the previous diagram:

Decision point of Gift-wrap
Outcome of Yes
Outcome of No
Gift-wrap Book process step

It could be that there are more outcomes from the decision point. Or that the decision point leads to another decision point, e.g. Red or Blue wrapping paper? More complex would be that some points are only available.

Notation
I've already mentioned the common use of a diamond for the decision point and that outcomes should be labelled. In addition, the text inside the Decision Point should be a question. And the outcome labels should be appropriate as answers to that question. Sometimes we have to abbreviate the responses due to space. Bear in mind it's all about communication, so think whether the readers will understand the abbreviated labels.

Ideally I'd have had a longer label for the decision point in the above example. My excuse is that I'm creating the maps on desktop software, then having to export in a way that works for this website. That's not the way I'd normally work, since I'd usually use the process modelling software that the client has bought into. I could still get a longer label but the process map suffices to show how decisions are depicted.

You may also see a decision point duplicated at the end of the options. i.e. the process would show a decision point, then the options/outcomes, then bring them all back to a further decision point (often empty). This just shows that the decisions have been resolved and that there's only the one path forward from that point on. This depends on the modelling standard you subscribe to.

Here's an example of that. I find that the additional decision point can confuse less-technical, more business-oriented readers. It also takes up more space on the screen or paper. So I tend not to use it that often or until a project is at a more technical stage.

The Most Common Mistake
The most common mistake I see in process mapping is that there aren't enough outcomes in the process map. The analyst may have assumed that the answer is yes or no. Often there are other outcomes, e.g. don't know, timed-out, incorrect response, didn't understand the response. It becomes more of an art than a science as to how many of these outcomes are included. Bear in mind that as more time passes and the project moves forward, then more of those outcomes should be documented.

Note the Ending
In the case of the gift-wrap example, the Process End is the same 'Book Bought' whichever outcome is taken from the decision point. That suits us because the Process of Buying a Book is still completed, regardless of whether the customer wants the giftwrap or not. It is possible to have different endings depending on the outcomes inside the process, we'll get to that later.

Is that sufficient?
In short, no. It's a start. Some of the first few steps in the process mapping journey. There is more to learn. For instance, we're not depicting who does what, what else they do, the details of paying for a book, or even what happens if we charge for the gift-wrapping. I stated it was a free promotion earlier since it allows us to focus on the decision point itself. I also want to go into more detail about how process steps relate to processes.

Checklist for decision points

Is the symbol noticeably different from process steps or other items? (actually not necessary, but very worthwhile if the process modelling tool allows it and most diagramming tools do).
Do the decision point have enough outcomes?
Is there a label on each outcome?
Does every decision point have a question as its label?
Do the outcome labels relate the decision point question?
Do all the outcomes connect to other items? (e.g. process step, process end, decision point)

Modelling Standards
I mentioned Modelling Standard above. I refer to standards such as BPMN or UML, specifically UML activity diagrams. In this series, we are starting with basic examples, moving towards depicting models conforming to those standards. The main thrust is to get the basics right and point out some of the common mistakes along the way. Watch out for different terminology, in BPMN the decision points are referred to as Gateways.

This is an article in the Fundamentals of Process Mapping online book provided by Award Sounds.

Process mapping - The Basics

Alan — Thu, 21 Feb 2008 13:28:26 +0000

Introduction

This is the first article in the Fundamentals of Process Mapping series. In the series, I want to discuss the areas that most process mapping tutorials miss.

In this bite-sized article, I'll introduce the idea of a basic process map.

Let's get some background about process mapping first.

What is a process map?
A process map is a tool. It is not an end in its own right. They are often used in software development lifecycle or within Business Process Re-engineering (BPR). If the methodology you're working in states that one is required, you're not writing a map just to fulfill that aim, but because the creators of that methodology realised that a process map would be a useful tool to have.

I see a process as one component of a process description, not necessarily the only component. That's worth remembering.

What are the purposes of a process map?

I have at least four aims when I'm process mapping:

To describe a process in pictorial form
To provide a quick way of understanding how the main steps in a process fit together
To provide documentation for agreeing what happens in a process
To provide documentation for what could happen in a process, e.g. process improvement

There are other aims depending on the need, e.g. for collaborative working, facilitating workshops. Whatever the discrete aims are, they all boil down to communication.

What are the components of a process map?
Every process has at least one process step, at least one starting point and at least one ending point. The process step is an action that is performed by an actor (either a person, a system or an organisation).

Our initial basic process will have the following:

one starting point
two process steps
one end point
connectors showing the direction of flow

For the process map here starts at Process Start, continues to Process Step 1. Once that is complete, continue to Process Step 2. Once that is complete, continue to Process End and the process is terminated.

To put that into context, imagine a simplified process for buying a book in a bookstore.

The customer wants to buy a book, so process start (Buy a Book), customer Chooses a Book, then Customer Pays for Book. Once that's complete, the Book is bought. I've simplified it so we can discuss it in more detail later on.

Notation
Your software may have different notation for process start/initiators, process ends/terminators and process steps (often just called processes). That's ok. As long as you can tell the difference between them.

What Next?
That's the very basics covered. I'll go into more detail about processes, process steps, decision points and common pitfalls in the following articles in the series.