A match made in heaven

Today a colleague asked me, “what is the relationship between the prototypes and the process maps?”

Process maps are an excellent articulation of the functional requirements of an IT system. Together with process notes that elaborate on the inputs and outputs they can be a powerful indication of what people do when they do their work and, therefore, what a system needs to do to support that work.

All too often, though, analysts jump into discussions with the data analysts, systems developers and designers, to create functional- and non-functional specifications and data models … but what about the people who’ll use the system? Is the discussion with them now complete?

On a recent project I worked on, we actually had no large tomes of functional and non-functional requirements, nor use-cases. Instead, we just used process maps and prototypes, and involved the users in their development. We held weekly workshops with the users to help us come closer and closer to understanding how people currently worked, how they wanted to work, how we could improve their processes and how we could develop a system that would support their wants and needs. With each pass we improved our process maps and notes and iterated our prototypes that articulated how the system would support the people using it.

Our first pass was at a rather high-level, creating storyboards to illustrate the flow of action and information. This helped us understand where:

• there were gaps in process
• the flow of processes weren’t logical, and
• systems could help people get the job done

On subsequent peels of this proverbial onion, we developed more detailed prototypes, starting with wireframes and finishing with high-fidelity interactive HTML prototypes that brought the functional requirements to life and demonstrated the non-functional requirements of accessibility, usability, and navigability.

This combination of process maps and prototypes proved very powerful — a match made in heaven. Rather than hand system users tomes of specifications they would not read, we were able to involve them in the evolution of artefacts they could see, understand, relate to, and immediately give feedback on. They could easily say “no we don’t do it that way” and “no, we don’t want to do it that way” (which they often did) so that we could develop a system that would support them in the way they wanted their work to be supported — user-centred design in action. And because we used an agile methodology, and iterated our prototypes, we could come back to them the next week with improvements to our prototypes and demonstrate that understanding. We could then take these improvements to the developers and show the intent of the system, show them how the users wanted it to work.

This way of working has obvious benefits for change management — the end result is a system with no surprises because its users have participated in its development. This approach also means you create artefacts that people will actually use and can be easily referenced by the developers to see the ‘how’ of the system as well as its ‘what’.

… try it some time. It works.

M

Bad English, Business Analysis and Business Analysts

For a long time English school teachers were taught that the rules for English should be like Latin — a dead language — and that it should follow these rules in all aspects. They then prescribed how English should be taught and how students should write and speak English. Some people refer to this as the Queens English and everything else as Bad English.

We all know, though, that English is a living language. It changes based on who speaks it, where they are speaking it, and who they are speaking to. You wouldn’t use the same style of speech to your grandmother that you would use to the kid down the street. This fact is why English isn’t taught prescriptively any longer in Australia. It’s taught descriptively — taught according to the way people use it.

It would be good if some of the new organisations around Business Analysis took this approach. Maria Murphy recently blogged about this — how some organisations are struggling to define Business Analysis so they can prescribe what it is. While they believe it will bring standardisation to the industry, I think it will just be like telling people who don’t meet the standard that they are speaking Bad English.

Maria suggests that we should be describing, rather than prescribing “the scope of what is business analysis and then … look[ing] at what that discipline offers in the way of frameworks and tools to its members, as [well as] the specialists in this field”.

I agree with Maria, but I would go a step further and say that we also need to look at what the discipline offers to the community who don’t call themselves BAs, but still do analysis work. BAs know what they do, but there are many people who don’t know what theories of analysis to draw upon, they don’t know what frameworks to use and when, and they don’t know what tools are out there to help them get the job done.

Let’s stop prescribing what a BA is and isn’t and let’s get these messages out there!

M

Associations, accreditation and certification: life-long learning, money spinner or bringing clarrification to the market?

Maria has been blogging on accreditation for Business Analysts. I know that there’s been discussion amongst the different disciplines of web development for years regarding professional associations, accreditation, and certification. A lot of it has been about trying to define what we do, clarifying and differentiation the different roles within web development, and determining measures for what constitutes a good practitioner and a mediocre one. I’ve seen a lot of discussion about accreditation and certification that is purely academic — a search for identity amongst a wide range of other analyst fields. Some of it is political — the fight control for dominance amongst peers in the community’s space. I’ve also seen that a lot of it is about business and making money.

What ever the motivation, does this bring any real clarification to the market? Does it enable us or our clients to differentiate between the poor practitioners and the good ones?

Let’s take Microsoft Certification as an example. IDC studies [1] into their programme yielded the following statistics:

• Certification improves project delivery and deployment - IT organizations with at least 25 percent Microsoft Certified staff had a 15 percent increase in projects deployed on time and within budget
• Organizations that have Microsoft Certified staff, reduce unscheduled downtime by 18%

On this issue, Don Spencer of the Waterloo-Wellington IT Pro User Group notes that certification (old and new) was useful for entry-level positions because it reduced the risk of hiring unqualified newcomers. Lack of certification, for seasoned professionals, stands in the way of securing any alternative job opportunity.

Jennifer Waters has been the manager of the CPLS (Certified Partners for Learning Solutions) channel and the Learning and Certification program for Microsoft in in Canada for the past 4 years. She believes in certification [2]:

…remember university, high school? Remember studying for exams? There were a ton of facts that you memorized but don’t remember any more. What all that studying gave you was broad knowledge. You might not remember the dates of WW II but you probably know what underlying factors triggered the start of it.

Certification is the same thing. There are definitely questions in the exams that rarely come up in real life, but it gives you a foundation to leap from. If you’ve got a ton of experience, it updates you and jogs your memory. Some of those out of the ordinary facts just might come up one day and if you are certified you’ll be the hero that solved them instead of that shmuck that you have to work with.

Jennifer’s suggestion here is that certification is about learning and not about giving clarity to the market — I think I’m ok with this idea. But this notion fails when we see certifications like ITIL evolving, changing, bringing with it the fear of rendering previous certifications redundant [3]. The business machine behind many of the programmes of certification decide, as time goes by, that what you’ve learned last time now requires a new piece of paper and several thousand dollars to confirm its relevance, and then proclaims this for all to hear — from practitioners to clients. Ultimately, this is more about political control and standardisation than it is about learning, and has little to do with educating clients about what is a good practitioner and a bad one. It’s like suggesting that Windows Vista is better than Windows XP because Vista is newer.

A university degree, however, aims to teach the fundamental theories and approaches that can be universally applied. When formal learning is complete, most university graduates then keep abreast of movements in their fields of expertise through channels like journals and research, and it becomes very obvious, very quickly, to other professionals, when they don’t. Here, the emphasis is on life-long learning and not pieces of paper.

I guess, all-in-all, this means that associations, accreditation and certification, attempt to be about life-long learning but because of the nature of commercialism probably end up being about money and only result in control of the market rather than bringing clarification. To this all I can say is ‘poor client’ to those who are fooled into thinking that a piece of paper with ‘version 3′ stamped on it has any real value, and ‘poor professional’ to those who have to pay $1,000 for it. I think I’ll stick to spending $10,000+ for a post-grad degree every 10 years or so for the learning it gives me.

M
—-

[1] IDC Study on Certification, 2003

[2] Waters, J. (2007). Does Certification Really Matter Any More? Technet Blogs, Monday, March 26. Online at: http://blogs.technet.com…matter-really-any-more.aspx

[3] The ITIL Imp (2006). ITIL Refresh v3 - Update, 10 October. http://itilimp.blogspo…v3-update.html