I should probably mention for the tiny minority of readers who don't know me that I'm not actually consulting anymore. I chose to contract directly about a month back as I got a particularly good offer at the right time and the time overheads of doing internal consultancy work and client work at the same time weren't compatabile with finishing off my MBA, while not compromise my religious learning.
It was excellent though - and I fully intend to send my resume back to the consultancy that employed me if I ever decide to go back to consulting. They are a great company.
P.S. My previous post comes out of thoughts I had about how to sell BAs as a service in a consultancy environment separate from delivery work, its just a coincidence that these posts are next to each other. No criticism of anyone intended.
Wednesday, January 13, 2010
Foxes & Henhouses
When you're beginning an important IT project you're no short of friendly Consultants, System Integrators, Product Vendors, and Outsourced Providers who are willing to offer their advice and help; all with the projects best interests in mind. Many of these provider will also provide you with Business Analysis services to aid in the execution of your project.
However there will come a time when the requirements of the business conflict with the interests of the stakeholders delivering the project, and your Analysts will always be in the center of these discussions – and whose side do you want them to be on?
How can your vendor supplied Analysts deal with a situation where the product they are selling doesn't meet your needs? How often has a consultancy sourced BA suggested anything that doesn't involve follow-up work for their consultancy? How often does a System Integrators BA ever advocate for a scope-increase, even when it's justified?
All of these conflicts of interest come to a head later in the project, typically around a table trying to civilly decide if a given change is a bug or a change request while everyone mentally calculated how much budget is left in the project, and how much slack was built into the profit margins anyway.
The horrible thing is that none of this is conscious - everyone always tries to do whats right. It's just that your views are so conditioned by the influences of your peers and your background.
However there will come a time when the requirements of the business conflict with the interests of the stakeholders delivering the project, and your Analysts will always be in the center of these discussions – and whose side do you want them to be on?
How can your vendor supplied Analysts deal with a situation where the product they are selling doesn't meet your needs? How often has a consultancy sourced BA suggested anything that doesn't involve follow-up work for their consultancy? How often does a System Integrators BA ever advocate for a scope-increase, even when it's justified?
All of these conflicts of interest come to a head later in the project, typically around a table trying to civilly decide if a given change is a bug or a change request while everyone mentally calculated how much budget is left in the project, and how much slack was built into the profit margins anyway.
The horrible thing is that none of this is conscious - everyone always tries to do whats right. It's just that your views are so conditioned by the influences of your peers and your background.
Sunday, November 29, 2009
Best User Interface Ever
I've just found the best user interface that has ever existed. It's a single button that does exactly what you want it do when you press it, there are just a few catches:
* You have to be a toddler
* It only works for radio controlled toys
* You have to want the toy to run around, and not particularly care where it goes.
Thankfully, this is for toddlers - who never care where a toy goes as long as it keeps going, so this is perfect!
What makes it so perfect is that the simplicity of the interface ensures that the toy basically never gets stuck in corners or under things. It transparently enforces a pattern of movement that gets you out of nearly anywhere!
So, how does it work? Well the toy only has two states
A) Going forward
B) Reversing in a clockwise circle.
If you hold down the button you go forward, once you let it go the toy reverses backwards. As a toddler this means that as long as I hold the button down (While yelling with joy) the toy goes forward, as soon as I get disappointed because it hits a wall, or wedges in a corner it reverses itself out.
In the worst situation if its really stuck I get angry because it's stuck and start pressing and then releasing the button (Which is what toddlers do by instinct) then I've done a three point turn and am out of trouble.
Best. Interface. Ever.
This interface is:
1) Appropriate to the user
2) Does what it needs to
3) Encourages the correct behavior in error situations
4) Doesn't get in the way of the experience
If I ever design a UI half as good as this for an IT system I will have done well.
This is the iPod shuffle of children's toys.
Even the device itself is simple, you can see below how the axle is housed in an arc so as long as its going forward it's straight but reversing immediately swings it around.
* You have to be a toddler
* It only works for radio controlled toys
* You have to want the toy to run around, and not particularly care where it goes.
Thankfully, this is for toddlers - who never care where a toy goes as long as it keeps going, so this is perfect!
What makes it so perfect is that the simplicity of the interface ensures that the toy basically never gets stuck in corners or under things. It transparently enforces a pattern of movement that gets you out of nearly anywhere!
So, how does it work? Well the toy only has two states
A) Going forward
B) Reversing in a clockwise circle.
If you hold down the button you go forward, once you let it go the toy reverses backwards. As a toddler this means that as long as I hold the button down (While yelling with joy) the toy goes forward, as soon as I get disappointed because it hits a wall, or wedges in a corner it reverses itself out.
In the worst situation if its really stuck I get angry because it's stuck and start pressing and then releasing the button (Which is what toddlers do by instinct) then I've done a three point turn and am out of trouble.
Best. Interface. Ever.
This interface is:
1) Appropriate to the user
2) Does what it needs to
3) Encourages the correct behavior in error situations
4) Doesn't get in the way of the experience
If I ever design a UI half as good as this for an IT system I will have done well.
This is the iPod shuffle of children's toys.
Even the device itself is simple, you can see below how the axle is housed in an arc so as long as its going forward it's straight but reversing immediately swings it around.
Monday, November 9, 2009
What sort of "consultancy" are you?
The word "consultancy" gets thrown around a lot and covers some very different organisations and value propositions. These range from just a few people sharing business-cards to true though to McKinsey.
1. Body Shop
At this stage you are just an outsourced agency to find contractors for clients. There are no real relationships between people on client sites it's just an volume game. The value proposition is just out-sourcing your interviewing and trawling through resumes.
2. Bunch-o-Mates / I know a guy..
At this stage one or two key senior people work as contractors out on client site, and bring in their friends and ex-colleagues to the same site. There's no real sales function it's all done through one-on-one relationships. The value proposition is a pre-assembled team of high-quality people.
3. Ad-Hoc Delivery / Hands & Feet
Once your bunch-of-mates hits a certain level of sophistication you can start to out-right own delivery of certain functional projects using whatever methods and IP is already used by the client. Commercially this is when serious profit and risk start to occur. Most organisation that delivery like this rely on one or two "heroes" (normally the owner) to actually deliver and manage client relationships.
4. Repeatable Delivery
Once you've gone through a few delivery cycles you actually start to know a thing or two about what you're doing. At this point you have the methods, IP, and embedded practices to actually reliably repeat delivery of similar solutions. At this point the founder starts to be less involved in the day-to-day and can probably start calling yourself a consultancy with a straight face.
5. Domain Expert
Knowing how to do it internally is great - but being able to pass that knowledge onto other is even better. In the Sydney market PlanIT for testing and Object Consulting for system modelling embody this trend well. Once you have a strong reputation you become sought out first for smaller consulting gigs to improve practice at clients, then as a plain old trainer.
6. Trusted Adviser
At this stage when you say no to your client they stop and listen and your ideas are incorporated into the heart of your clients strategy and execution. You're a trusted source of option and options in your domain or beyond. Congratulations. You don't need to be McKinsey, even if you're just a trusted adviser of a specific domain like data warehouses or mail-rooms that's a great achievement.
(Got some ideas from here while goggling good examples of trusted advisers)
http://onstartups.com/tabid/3339/bid/1699/Startups-Are-You-A-Trusted-Adviser-Or-A-Responsive-Assistant.aspx
1. Body Shop
At this stage you are just an outsourced agency to find contractors for clients. There are no real relationships between people on client sites it's just an volume game. The value proposition is just out-sourcing your interviewing and trawling through resumes.
2. Bunch-o-Mates / I know a guy..
At this stage one or two key senior people work as contractors out on client site, and bring in their friends and ex-colleagues to the same site. There's no real sales function it's all done through one-on-one relationships. The value proposition is a pre-assembled team of high-quality people.
3. Ad-Hoc Delivery / Hands & Feet
Once your bunch-of-mates hits a certain level of sophistication you can start to out-right own delivery of certain functional projects using whatever methods and IP is already used by the client. Commercially this is when serious profit and risk start to occur. Most organisation that delivery like this rely on one or two "heroes" (normally the owner) to actually deliver and manage client relationships.
4. Repeatable Delivery
Once you've gone through a few delivery cycles you actually start to know a thing or two about what you're doing. At this point you have the methods, IP, and embedded practices to actually reliably repeat delivery of similar solutions. At this point the founder starts to be less involved in the day-to-day and can probably start calling yourself a consultancy with a straight face.
5. Domain Expert
Knowing how to do it internally is great - but being able to pass that knowledge onto other is even better. In the Sydney market PlanIT for testing and Object Consulting for system modelling embody this trend well. Once you have a strong reputation you become sought out first for smaller consulting gigs to improve practice at clients, then as a plain old trainer.
6. Trusted Adviser
At this stage when you say no to your client they stop and listen and your ideas are incorporated into the heart of your clients strategy and execution. You're a trusted source of option and options in your domain or beyond. Congratulations. You don't need to be McKinsey, even if you're just a trusted adviser of a specific domain like data warehouses or mail-rooms that's a great achievement.
(Got some ideas from here while goggling good examples of trusted advisers)
http://onstartups.com/tabid/3339/bid/1699/Startups-Are-You-A-Trusted-Adviser-Or-A-Responsive-Assistant.aspx
Wednesday, November 4, 2009
Reports for people not databases
Collecting reporting requirements needn't be a boring experience. Too often we try and specify lots of functional detail about the report that doesn't really help instead of concentrating on what's most important. That's why I use user stories to document the reporting stakeholder requirements as well. Just use the following form:
The crucial piece of information is how people are going to use the report, what value it adds, and what will be done as a result of the information it contains.
This is the basis of your design, if you get this right the form design flows naturally, if you get it wrong no amount of detail in the report specification is going to save you.
Your reporting requirements shouldn't be relegated to some technical back-water. Theses reports are often the widest public interface to your application, and often the view that the most senior users of your application will see.
If you're willing to put in the effort to separate problem elicitation from solution definition for your functionality, you should be willing to do the same for your reporting.
P.S. Getting your logical model right is an absolutely necessary pre-requisite to the functional design. If you don't get that right your're bound to fail.
- As a report consumer
- I want to know the answer to some questions
- So that I can make some decision and take some action
The crucial piece of information is how people are going to use the report, what value it adds, and what will be done as a result of the information it contains.
This is the basis of your design, if you get this right the form design flows naturally, if you get it wrong no amount of detail in the report specification is going to save you.
Your reporting requirements shouldn't be relegated to some technical back-water. Theses reports are often the widest public interface to your application, and often the view that the most senior users of your application will see.
If you're willing to put in the effort to separate problem elicitation from solution definition for your functionality, you should be willing to do the same for your reporting.
P.S. Getting your logical model right is an absolutely necessary pre-requisite to the functional design. If you don't get that right your're bound to fail.
Sunday, October 11, 2009
Reply quickly without being rude
To clear up a backlog of email its sometimes necessary to write very short answers, which can offend some people.
So change the email signature on your desktop email client to "Sent from my Mobile Device. You can then reponse as briskly as you like without fear of causing offence as everyone will assume you were pecking away on a smart phone.
--
Sent from my mobile device
So change the email signature on your desktop email client to "Sent from my Mobile Device. You can then reponse as briskly as you like without fear of causing offence as everyone will assume you were pecking away on a smart phone.
--
Sent from my mobile device
Wednesday, October 7, 2009
Use Cases happen Between Coffees
If you remember this one thing you will practically never go wrong with getting your use cases at the right level of granularity.
Use cases end whenever the user would comfortably get a cup of coffee. This probably goes for process tasks as well. All my ramblings about Elementary Business Processes are just commentary to this idea.
(For a long time I was walking around saying this without realising it was a Cockburn line. So I hereby retroactively credit him for all my past uses of this concept without accreditation. It wasn't until a recent IIBA newsletter I even realised it came from him.)
Use cases end whenever the user would comfortably get a cup of coffee. This probably goes for process tasks as well. All my ramblings about Elementary Business Processes are just commentary to this idea.
(For a long time I was walking around saying this without realising it was a Cockburn line. So I hereby retroactively credit him for all my past uses of this concept without accreditation. It wasn't until a recent IIBA newsletter I even realised it came from him.)
Subscribe to:
Posts (Atom)
Posts
