Business Analysis Diaries

THE "GET IT ALL DONE NOW" GAME

colart@gmail.com (Colart Miles) — Tue, 26 Sep 2017 09:09:00 +0000

We'd like to share a simple exercise that helps people understand how hard it is to be productive when they get too busy. You can do this on your own (it only takes 5 minutes) or you can try it with an audience.

We call it the "GET IT ALL DONE NOW" Game :-)

THE "GET IT ALL DONE NOW" GAME

The game works particularly well with larger audiences (any size theoretically).

Before you start: Make sure you have 15 minutes set aside for the whole exercise and make sure your audience is armed with a pen and a piece of paper each.

STEP 1) THE SETUP

As the facilitator you'll need a white board or flip-chart to write up the results. Prepare something like this:

Display a presentation slide (or poster) with the following three lines:

Here's the back story to set the scene for your audience:

"...You're each employed by our company and you are here to serve these three customers as quickly as possible. Your job will be to write down these three lines on your own piece of paper but there's a catch..."

STEP 2) THE 1ST SCENARIO

"The catch is...

a) We have a strict company policy that no customer should be left waiting so you will need to deliver all three sentences at once and

b) We like to measure how fast this happens so please put your hand up when you have completed the task

..."

Setup a stopwatch that has a lap timer feature (smart phone apps tend to work well).

Check for any questions and then launch the exercise!

Take a 'lap' time every time someone raises their hand until everyone is done then stop the clock.

Jot down the results... a) Earliest finish time... b) latest finish time... c) approximate average time....

Move on to STEP 3

(NOTE: YOUR AUDIENCE SHOULD COPY THE LINES IN THE PATTERN BELOW)

Note: The pattern should look something like this... all three customer jobs simultaneous

STEP 3) THE 2ND SCENARIO

"...Well done everyone... OK, our company has been learning about LEAN thinking and we've decided to fire the previous manager and establish a new customer policy... We're going to rerun the exercise only this time you're only allowed to work on one customer at a time..."

Check for any questions and then launch the second exercise!

Take a 'lap' time every time someone raises their hand until everyone is done then stop the clock.

Jot down the results... a) Earliest finish time... b) latest finish time... c) approximate average time....

Move on to STEP 4

(NOTE: THE PATTERN SHOULD LOOK SOMETHING LIKE THIS)

Note: the pattern should look something like this

STEP 4: THE LEARNINGS

Try to get your audience to share their experiences... Some questions to get things started might be:

· How did the first run feel? chaotic... difficult...

· How did the second run feel in comparison? easier... more flow... smoother

· Which approach gave the fastest overall response?

· Which approach gave the fastest time to first value?

· Which approach felt more productive and less wasteful?

By the end of the exercise you should have something like this:

Some of the key insights to conclude with:

· Limiting Work-In-Progress increases throughput

· Focusing on one thing at a time is faster, better and cheaper... every time

· Teams that are able to focus on less tend to deliver better quality, faster and are more able to sustain their pace (i.e. achieve their flow state).

So why doesn't everyone understand and use these principles more widely you might ask? Well there is a traditional management view (that's still very prevalent) that compels managers to make sure that every employee is utilized to the maximum.... in other words, it's important that everyone is kept busy... all the time... This approach directly undermines productive throughput and prevents teams from finding their true potential.

JOIN THE REVOLUTION... STOP THE GLORIFICATION OF 'BUSY'!

-->

P.s. We hope you found this article useful and if you do use this exercise please let us know how it went :-)

9 Project Management Commandments to live by

colart@gmail.com (Colart Miles) — Tue, 31 Aug 2010 22:13:00 +0000

I'm coaching a very successful software company in Auckland on the finer points of Project Management. The 9 commandments that follow represent an accumulation of wisdom that has served me well over the years. Please feel free to share your thoughts on the matter.

Begin with the end in mind

Plan the flight... then fly the plan
Pause for agreement and clarity before implementing
Stay wedded to the outcome, not the path for getting there
The worst time to define success is after it’s over

Manage by result, not activity

An active team is not necessarily a productive team
Focus on Throughput
Limit Work in Progress
Learn to use teams to achieve results... not individuals.

Compromise on scope not quality

Define ‘quality’ upfront (e.g. verification criteria)
Understand technical debt
Learn to recognize an ‘interest’ payment from a ‘capital’ payment. (i.e. treat causes as well as effects)

Escalate early and often (e.g. 2X2X2 Escalation)

2 minutes to explain the issue
2 minutes to describe options
2 minutes to make a decision on what to do next

Continuous Course Correction

Invest in short regular planning exercises.
The act of planning is more valuable than the plan!
Learn to surface impediments/blockers regularly
Planning exercises are for planning the work not doing the work!

Serve your team

Enable your teams with clear decisions, clear priorities and lot’s of encouragement
Double the rate of failure!
Trust your experts

Manage the context

Maintain situational awareness outside of the team
Make yourself aware of ALL the stakeholders
Create an atmosphere that celebrates failure as a learning experience
Communicate little bits of news often!

DWYSYWDWYSYWDI

Credibility is critical to building trust
Do What You Said You Would Do When You Said You Would Do It .

Retire risk early

Tiger cubs are easier to deal with than tigers!
Prioritize first... sequence last.

How can corporations best fight atrophy?

colart@gmail.com (Colart Miles) — Sat, 28 Aug 2010 01:14:00 +0000

How can corporations best fight atrophy?

I was listening to a podcast a while back* by Ried Hoffman (who started LinkedIn and Paypal) and something he said got me thinking about corporate atrophy**.

Ried mentioned how easy it was for Paypal to out maneuver the larger banking bodies during the startup phase. They were busy testing the legal definition of a bank with their online offering and the banks were squirming and nearly powerless to respond. In fact some of the banks online counter offerings took in excess of 12 months to deliver... as Ried correctly points out, thats an eon in internet time!

Just how did the banks get to this lethargic state?

And how can they (or any large corporate body for that matter) hope to compete in this rapidly changing business environment.

More to the point, How can corporations best fight this atrophy?

*For Rieds Podcast: http://edcorner.stanford.edu/authorMaterialInfo.html?mid=1650
** Definition of atrophy: http://www.thefreedictionary.com/atrophy

I posted this question in LinkedIn and got quite a few interesting suggestions back:

Mergers & Acquisitions
>>Let others take the big risks and buy them up when they look promising.

Various forms of Internal Entrepreneurialism
>> Google have an interesting internal policy where they allow thier employees to use 20% of their worktime to work on anything they want. They have enjoyed an enormous amount of success from the projects resourced this way.

9 Top Tips for starting an Agile Project

colart@gmail.com (Colart Miles) — Thu, 03 Jun 2010 07:43:00 +0000

Set-up a planning session with the project sponsor... get them to share the vision... identify the Success Criteria (I.e. the conditions under which the vision will be considered realised)
Use Rob Thomsett's project success sliders to define the degree of flexibility in the different dimensions.
Derive SMART Objectives (Specific, Measurable, Achievable, Realistic and Timely)
Create a Product Breakdown Structure
Turn this into a Product Flow Chart and use this to communicate the project roadmap to both the team and the sponsor.
Use Mike Cohn's planning poker to estimate the relative weighting for each of the main products on the roadmap.
Establish a burndown chart to track 'speed over ground'.
Propose that your project sponsor gives the status reports on the project.
Re-plan the project regularly. Keep checking that the project goal is still the same (i.e. progressive elaboration)

7 SCRUM insights from Jeff Sutherland and Jens Ostergardt

colart@gmail.com (Colart Miles) — Thu, 04 Mar 2010 00:45:00 +0000

Jeff Sutherland, the inventor of SCRUM and Jens Ostergardt, the 1st SCRUMMASTER, were keynote speakers at the APN in Auckland last night.

Here are a couple of salient points I took from the talk:

Jeff was a fighter pilot in Vietnam (Sydney 1967) and flew over 100 missions! This along with Jeff's subsequent experience in medical sciences seems to form the backdrop to the pre-scrum thinking. Jeff said he came up with a process that is in a constant state of response to impediments.
Jeff appears to be a scientist at heart with an evidence based way of getting his point accross. One of the stats he mentioned was that an average 63% of features change on development projects... I'm still digging for the reference for this... will post it shortly.
When coaching senior management teams Jeff seemd to emphasize the need to "surface impediments". He cited a great example of a Danish company that was level 5 on CMMI with excellent control over processes. This was used as the test bed for determining the productivity differences between SCRUM & Waterfall... needless to say SCRUM kicked ass ;-)
Read the MIT iRobot story. I loved this story as it really brought home the need to establish the learning process with simple rules... The world is the database... simple rules give rise to sophisticated behaviours!!!
Jens gave some valued advice for new ScrumMasters:

Don't get fired,
Resist the urge to 'help' the team
Don't use a SCRUM tool at first! (Help the team find it's feet (low tech) before introducing tools.)

Jeff seems to enjoy applying Root cause analysis for SCRUM issues... Let the data reveal the causes. He gave one of his Polish companies as an example. The company in question had been advised to implement integration testing... this was ignored and later identified as a root cause of the ensuing spate of iteration failures.
Lack of integration testing was identified as a major impediment to getting to DONE!

Hope you enjoyed this installment... If you attended the event too please feel free to add your own take on the talk!

This event was arranged by Edwin Dando from Clarus Consulting in Christchurch. A real win for the New Zealand Agile community I'd say!!

Handling 3rd party vendors on SCRUM projects

colart@gmail.com (Colart Miles) — Tue, 02 Mar 2010 01:43:00 +0000

A friend of mine recently asked me what the best way was to manage a 3rd party vendor on a SCRUM project. (SCRUM is an Agile Methodology for those of you who don't know)

Here's the advice I gave him:

Get the vendor relationship off to a healthy start:

Make sure there's an open, honest and safe channel for the vendor to communicate with you.
Be as specific as possible with what you require from them. Try and be results focused and not activity focused. Here's a great article by Marc McDonald on the merits of results versus activity management.
Urge vendors to give commitments that you can rely on and not commitments that you may want to hear.
As a rule of thumb question the assumptions behind an estimate and not the estimate itself. This way your vendor is encouraged to use their expertise while protecting their self esteem (improves their perception of safety).
Try and use the language of 'confidence' when considering estimates. For example, "The vendor is very confident in a 5 day delivery" or "The vendor is not very confident in a 5 day delivery due to an issue with XYZ". This way you're less likely to set unrealistic expectations with stakeholders.
Ask your vendors to escalate potential issues early and often... better to handle things early & cheap than late & expensive. (See my previous blog article on this)
Work hard to empower your vendor... especially since their performance has direct impact on your reputation. In other words, your reputation will very likely take a knock if they flounder.
Prioritise the deliverables you're expecting as much as possible. Be clear about Must Haves.
Compromise on Scope not Quality where possible. Don't make them deliver things if it can't be done properly. For example if you're time pressured, negotiate with scope.

Integrating vendor deliverables with your SCRUM project:

Create a user story card for their deliverable and place it in the product backlog.
When the iteration arrives be sure to schedule integration and testing tasks in the sprint backlog to ensure the vendor deliverables are truly DONE by the end of the iteration.
For planning poker, Limit the task estimates to just those your team will need to carry out. I.e. exclude any work your vendor will do as this will distort your view of velocity (... thanks Vasco)
Invite your vendor along to attend the sprint planning meeting for the relevant iteration. A public commitment to the team to meet a deadline is always more powerful than a contract ;-)
Be sure to regularly ask vendors how they are tracking and to confirm their delivery estimates (weekly should be ok).
If there are dependancies on the vendor's work be sure to assess the impact of delays. Communicate the potential impacts to stakeholders early.
The vendor should also attend the sprint review to see how their deliverable has been integrated and to clarify anything should the need arise.
It's also ideal to have your vendors attend the relevant sprint retrospective to get their input.

3 Steps To Winning Over Your Most Difficult Stakeholder.

colart@gmail.com (Colart Miles) — Thu, 18 Feb 2010 22:24:00 +0000

3 Steps To Influence Stakeholders on Prezi

An important part of a good Business Analyst's tool-set is the ability to engage and influence key stakeholders.

Here's a simple model I use to develop meaningful and lasting professional relationships with my stakeholders be they managers, project people or juniors:

Over a period of time (i.e. one or more meetings or interactions) make sure you move through the following phases:

Step 1: MATCH

The main goal for this phase is to empathise as much as you can. In other words walk a mile in thier shoes.

Actively demonstrate that you are working to understand their view of the world. Take opportunities to stop the conversation and "play back" what you've heard.

Listen out for opportunities to add value in small ways. (e.g. mention an online resource that may be helpful for them)

Whenever you interact be sure to mirror body language, tone of voice, language. Sounds cheesy but it works!

Step 2: PACE

After you've practiced matching for a while you should be more 'in tune' with their way of thinking.

Conversations should flow quite easily and your stakeholder should be quite relaxed.

You should also have a good understanding of what they want or what thier concerns are.

In this phase you focus on keeping the momentum going. Feedback things that you know they would be interested in.

Make sure you keep any promises made in conversation even if it may seem trivial. (This is crucial for building credibility!!)

You know you're getting this part right if you can finish their sentences!

Step 3: LEAD

Be outcome oriented. Stay wedded to the outcome and not the method of getting thier!!!

This is when you start bringing in your agenda in a very respectful way.
Start by telling the reason for talking to them. Ask them for some time to explain your point of view.

Be open to comments and treat questions or concerns with respect.

Respond to comments as if you were looking at your message alongside your stakeholder.

Ask them what they think the best way is to proceed.

Respond to thier advice. Show that you are able to be influenced.

This model has served me well over the years and really helps remind me to listen before presenting.

If you're interested in where this model came from have a look at the NLP wiki.

M-Commerce: Did anyone see this coming?

colart@gmail.com (Colart Miles) — Tue, 26 Jan 2010 09:55:00 +0000

The language of commerce has changed dramatically in the last two decades especially with the growing popularity of trading electronically.

However no-one could have predicted the popularity of the mobile phone and the subsequent form of commerce it has given birth to. Dubbed m-commerce, early adapting countries such as Japan and the U.S. are enjoying a massive surge from this channel and it's only going to get better.

The International Telecommunication Union published a recent report on global ICT statistics and it states that the number of mobile phone subscriptions now exceeds 4.6 billion... That's 67% of the world's population with a mobile phone!!! (http://www.itu.int/ITU-D/ict/material/Telecom09_flyer.pdf).

If you're formulating a strategy for the next ten years don't forget to check what kind of impact this will have. I'm giving my R&D team a call as soon as I get back in the office to ask whether they've got anything in the pipeline in m-commerce!

By the way, Wikipedia gives a great overview of the business applications of m-commerce.

Promoting Ethical Behaviors in the Business Community

colart@gmail.com (Colart Miles) — Mon, 23 Nov 2009 21:45:00 +0000

This article examines the proposal that “…Corporations and the people who make them up must have high moral standards and monitor their own behaviour because there are limits to what the law can do to establish and ensure that business behaviour is socially and morally acceptable” (Shaw, Barry and Sansbury, 2009, p.206).

We begin by identifying the parties involved (i.e. the message giver and message receiver), clarifying a number of preliminary concepts and then applying ethical theory to deepen our insight on how they might respond. The discussion concludes by suggesting an alternative approach that would achieve the desired outcomes implied by Shaw et al. (2009) by appealing to the business community’s sense of enlightened self interest.

Discussion

There appear to be two parties to this statement; the message giver represented by Shaw et al. (2009) and the message receiver being the business community at large. I believe Shaw et al. (2009) is attempting to induce the business community into becoming more ethical in their behaviour. Given that the business community is primarily concerned with the outcome of generating value for shareholders, I would suggest that the ethical position for most (if not all) of the target audience members could be classed as consequentialist in the way Crane and Matten (2007, p.91) describes it. On the other hand, the stakeholder orientated language used by Shaw et al. (2009) suggests a non-consequentialist ethical position.

In the discussions that follow we will consider the key ethical responses to this statement however first there are a few preliminary concepts to clarify for the purposes of this essay; i) the assumptions underlying the statement, ii) a definition of morality and iii) origins of morality.

i) Assumptions underlying the Shaw et al. (2009) Statement

During the discussions on how the business community might respond we will reduce the Shaw et al. (2009) statement to the following key assertions:

1) Corporations have an obligation to maintain high moral standards.
2) Individuals have an obligation to maintain high moral standards.

3) Business behaviour is currently socially and morally unacceptable.
4) High moral standards are both definable and attainable.
5) Self monitoring of business behaviour will address the perceived gap left by the legal system

ii) Definition of Morality

Wines (2007) describes morality as the rules people have within them to operationalize their va

lues. However for the purposes of informing our sense of moral standard we will use the Crane et al. (2007, p8) definition of morality:

“Morality is concerned with the norms, values, and beliefs embedded in social processes which define right and wrong for the individual or community” (Crane and Matten, 2007, p.8).

ii) Origins of morality

Dawkins (2006) offers an interesting commentary on the origins of morality in human beings. Dawkins (2006) suggests we are genetically predisposed to be moral and that these char

acteristics emerged from the lengthy evolutionary process. He cites in his supporting argument; genetic kinship, reciprocal altruism, reputation (of altruism) and advertising altruism to support this proposition (Dawkins, 2006, p.219). In essence individuals are statistically more likely to benefit if they adopt a behavioural strategy that exceeds a critical frequency in the population. This seemingly natural mechanism appears to have given rise to the complex moral awareness that human beings have today. Given our interest here in promoting ethical behaviours it’s important to understand how this natural mechanism can work in favour of improving the overall ethical disposition.

Apart from some evolutionary compulsions to exhibit altruistic behaviours the question of why we should be moral appears to be a key topic for ethical philosophers. Melden (1948) and Frankena (1958) seem to think this is an impossible question to answer due to, amongst other things, the difficulties defining ‘good’. Doing ‘good’ it seems, is a matter of perspective and there are many perspectives to choose from.

For the purposes of this essay, we will assume that what constitutes ‘good’ is in the eye of the beholder and in this case the beholder is the business community at large.

According to Crane et al. (2006), there are two consequentialist theories which may help us to understand how the Shaw et al. (2009) statement might be perceived by the business community. These are Egoism and Utilitarianism.

An Egoist interpretation:

I think this type of ethical lens (Crane et al., 2007, p.110) would feature strongly in the minds of the business community both as individuals and as a collective. The Egoist is chiefly concerned with their individual self-interest (Crane et al., 2007, p.93). To an Egoist business person reading this statement, the idea that individuals have an obligation to maintain high moral standards would certainly strike a chord. Especially since this would probably mean having to comply with an imposed set of moral standards that challenges their freedom of choice.

In a world where Shaw et al. (2009)’s statement has been realized, the Egoist would be looking for a personal benefit and probably won’t find one. I doubt whether the Egoist will care about corporate obligations or how business behaviour is currently perceived. On the other hand the Egoist may treat this statement as an opportunity to develop a moral façade as a way to enhance

career prospects. How this might be utilitised is of more interest to the next perspective, Utilitarianism.

A Utilitarian interpretation:

I think the Utilitarian business person would look at the Shaw et al. (2009) statement from a cost to benefit viewpoint. On the cost side the main part might be the moral obligations for both individuals and corporations over and above those required by company law. From the statement (Shaw et al., 2009) it’s not clear how onerous a high moral standard might be to maintain however it is likely to be a significant social investment. A move to this new moral world would also likely impact other social systems such as; the legal framework for businesses or the welfare system not to mention changes to the role of management. Corporations would be saddled with yet more obligations besides the usual shareholder focus.

On the benefit side meeting these obligations might position businesses well to meet an increasing public demand to behave ethically (Crane and Matten, 2007, p.9). Behaving ethically may actually be good for business according to research by Hosmer (1994) and commentary by Covey (2006). The utilitarian might also consider the distribution of benefits to be an improvement since an overall improvement in moral judgement might lead to better circulation of wealth. In my opinion the Utilitarian might view this as a worthwhile investment to make.

For Shaw et al. (2009) to appeal to consequentialists, it would need to use the language of outcomes. Outcomes that are ecologically checked and inform the participant not just on what needs to be achieved but also how it should be achieved. We now turn our attention to a compelling economic case put forward by Covey (2006) for improving ethical behaviour which would appeal to both the Utilitarian and Kantian perspectives.

Business behaviours to improve the organisational climate

I’d like to present a slightly different way of engaging the business community to achieve the same ends. To persuade the consequentialist business folks to adopt a form of enlightened self interest. That is to change to a self serving mode of existence designed to generate systemic trust.

In his latest book, ‘The Speed of Trust’, Stephen Covey (2006) proposes that trust (in organisations) affects two outcomes, speed and cost. When trust diminishes (often as a result of unethical behaviour), speed decreases while cost increases (Covey, 2006, p.13). Conversely if trust increases, speed increases and costs decrease (Covey, 2006, p.13).

This can be expressed as follows:

Figure 1. The economics of trust (Covey, 2006, p.13)

This relatively simple formula gives us the means to use a familiar language to influence business behaviours by quantifying ethical decision making in economic terms. For the Utilitarian perspectives this would support the business case ethos especially since the cost/benefits could easily be articulated. Kantian protagonists and relationship oriented perspectives (such as feminist ethicists) will enjoy the principle-centered implications of promoting trust as an attribute that can be actively cultivated.

Covey (2006) proposes a number of conduct changes that will dramatically improve levels of trust and judging from the level of book sales, this message seems to have caught the attention of the business community. ‘The Speed of Trust’ remained in the top 10 of the New York Times best seller list for 6 months (NY Times, 2007). I believe a campaign of winning hearts and minds will achieve much more than simply imposing these conduct changes with policies, codes on conduct or other methods of corporate coercion.

Conclusion

In conclusion, we have considered the statement made by Shaw et al. (2009) from the business community perspective paying particular attention to the ethical lenses described by Crane et al.(2007, p.119) of Egoism and Utilitarianism. Engaging the business community by projecting a set of values and obligations on them is not likely to achieve the outcome Shaw et al. (2009) desired. To address this we have suggested a more enlightened approach that appeals to the inherent self-interest in the community. An approach that achieves a more evolved mode of existence that is designed to generate trust system wide to the benefit of all.

References

Covey, S. M. R. and Merrill, R. R. (2006). The Speed of Trust. New York. Free Press.

Crane, A. and Matten, D. (2007). Business Ethics. London, Oxford University Press.

Dawkins, R. (2006). The God Delusion. London, Bantam Press.

Frankena, W. (1958). Macintyre on Defining Morality. Philosophy, Vol. 33, No. 125 (Apr., 1958), pp. 158-162, London, Cambridge University Press. Retrieved November 20, 2009 from http://www.jstor.org.ezproxy.massey.ac.nz/stable/3748565

Hosmer, L. T. (1994). Why Be Moral? A Different Rationale for Managers. Business Ethics Quarterly, Vol. 4, No. 2 (Apr., 1994), pp. 191-204. Retrieved November 20, 2009 from http://www.jstor.org/stable/3857491

Shaw, W. Barry, V. and Sansbury, G. (2009) Moral Issues In Business, Melbourne, Australia: Cengage Learning.

The New York Times, (2009), Best Sellers, Retrieved November 22, 2009 from http://www.nytimes.com/2009/04/05/books/bestseller/bestpaperbusiness.html?_r=1&scp=1&sq="speed%20of%20trust"&st=cse

5 easy steps to applying the entrepreneur's lesson to your next project:

colart@gmail.com (Colart Miles) — Tue, 08 Sep 2009 20:21:00 +0000

Step 1) Analyze the core requirement that your deliverable is addressing.

This is very much about WHAT your deliverable is trying to achieve as oppose to HOW. The answer will give you greater flexibility when generating pilot options.

Step 2) Conceptualize a Pilot version of your deliverable that meets this requirement.
As a rule of thumb, aim to scale the solution down to about 25% of the original budget.

Step 3) Plan to pilot this release to a select set of target users.
Identify and engage your customers early. Prepare them for the release and how they can best help out. Make sure you establish several ways for them to communicate with your team.

Step 4) Set-up your development resources to respond quickly to feedback.
Make sure your own team is setup to capture and manage the changes in the following releases.

Step 5) Start planning a series of releases as required.
Be ambitious with your delivery dates. Constantly re-prioritize the tasks to maintain alignment with the overall requirement. Think Triage! Follow this up with a schedule of release dates and commit to them publicly.

5 useful WolframAlpha features for Business Analysts

colart@gmail.com (Colart Miles) — Wed, 20 May 2009 09:42:00 +0000

WolframAlpha has finally launched and this article takes a look at some of the features that may be useful to the IT crowd. If you're looking for a good explanation of what WA is then have a look at Stephen Wolfram's intro.

1) Estimation tools

Next time you ask your developers for an estimate point them to Wolfram's excellent set of metric computations...

Spotting trends can be hard however Wolfram can give you several perspectives on simple data streams. Drop a sequence of numbers in and the output will be several computational perspectives that will help you to spot patterns or even trends. Pretty useful when building estimation models. Try these statistical examples.

2) Present Value and other financial features

Essential for Cost Benefit Analysis, Wolfram provides a several view of projected value earned over time. Here's an example.

3) Website info

Drop your own URL in and see a breakdown of statistics. Still a bit basic but I think it has potential.

4) Historical Money

Great little feature that allows you to find out the value of money at different points in time. For instance you could find out how much $100 USD in 1900 is worth today.

5) Salary and wages

Wolfram allows you to input different job titles and returns the salary stats for comparison. These can even be targeted to a specific location. I've tried a few variations with out much success but I suspect this feature will be developed as the demand ramps up.

The release of a computational search engine like WolframAlpha is a very significant event and although this tool won't compete directly with Google, I believe it's on a par. Technologists and business people should definitely take note.

8 of my favourite Agile RSS Feeds

colart@gmail.com (Colart Miles) — Thu, 30 Apr 2009 03:26:00 +0000

Thought I would share the list of my favourite RSS feeds on the topic of Agile. They've helped me through some difficult times and continue to be a great resource for guidance and support.

P.s. if you're not familiar with RSS feeds have a look at this tutorial: how-to-getting-started-with-rss

Design upfront or let your architecture emerge?

colart@gmail.com (Colart Miles) — Sat, 28 Mar 2009 21:07:00 +0000

Our team is looking at rolling out a new technology stack (enterprise wide) called Pega Rules Process Commander (supported by Pega Systems and considered to be top of the Gartner magic quadrant for BPM Suites). This being the beginning of the journey there were a few obvious architectural questions to address. I was particularly concerned about the base class structure knowing from experience that this is the part to get right at the start.

On a mission to get some answers I went along to the annual Pega symposium in Sydney in February. The clear steer I got from the Pega team (including Alan Treffler) was to hold true to an agile philosophy and allow the architecture to emerge. Meaning to build the initial application using as much of the existing generic structure as possible in the first couple of iterations. In the retrospective, determine the gap between where you want the structure to be and where it actually is. Use this knowledge to make conservative specialization decisions for the classes. Essentially this will instill an important re-use enabler discipline within the development team.

This seemed a little counter-intuitive to me especially since the first project was intended to be the first of many rolling this technology out as a core capability for the company. Who knows what the next business problem may look like? The cost of 'getting the class structure wrong at the start seemed far too high to dismiss. Now consider the alternative...

The natural counter approach is to design as much of the class structure upfront (using techniques like detailed business domain modeling)... This smacked heavily of waterfall and seemed to be the safest route... "NO!" I thought "I absolutely won't give in to that kind of fear driven logic!"

Digging a little deeper with some of Pega's other customers and with our sister company in Australia, I started to get a feel for the actual cost of changing our minds about the class structure and it appears this topic is well addressed. However it depends entirely on the development approach your team takes. Pega actively discourages waterfall when using their suite however this doesn't proclude customers getting value out if they're constrained by traditional SDLC views. It just means that the potential for re-use and agility is more likely to remain locked up.

Pega supports alterations to the base class structure and more importantly they actively promote a 'build for change' philosophy for implementers.

In summary, my opinion is that it comes down to a combination of an organization's outlook and risk appetite. If they're a bit more contemporary and understand the dynamics of innovation (i.e. learning frameworks such as SCRUM) then allowing the architecture to emerge is a 'no brainer'. On the other hand if the organization is still struggling with a traditional theory based philosophy (waterfall for example) then 'design upfront' will certainly ease anxiety and get things going.

================= LnkedIn Q & A ==================

I posted this question on LinkedIn and here are a few answers I got back:

From: Paul Williams

Colart,

I think that there's a balance. My most successful projects were front-end designed to a point, then evolved from that. In essence, the core -- backbone, if you will -- of the frameworks were designed cathedral style. The application modules, then, were "evolved", bazzar style.

Occasionally, a requirement of the application would necessitate an adaptation of the framework (or a really useful component would be promoted into the framework), and thus the framework also evolved, but always and only within the spirit of the initial design.

In contrast, the application components were ad-hoc, whatever you please to get the client happy.

From: Olaf Dietzler

I believe that the term "architecture" is actually defining a few basic principles.

- Stability
- Scalability
- Integration and interfaces

The point of having an architect (both for IT and buildings) is to at least provide a framework in which technology can support business changes, both in function and volume without the whole thing coming apart.

An architect doesn't neccessarily need to define up front what colour the walls are going to be or what flooring is beeing put into the building, but he should have provide walls (which can be repainted in different colours) and a level base, so that when the flooring is beeing placed (or replaced) without harming the foundation.

Regards,
Olaf

From: Tony Fairhurst

I find the best approach is to define a business strategy. What are the goals of the business over the next 2,3,4,5 years. Once this had been understood, you can produce a roadmap of how to get there. That doesn't mean you won't deviate from the roadmap, but at least you will know you have and why you have.

The Key for any EA is to build in, Agility, Adaptability, Re-usability into the big picture view. If these principles are adhered to then the evolution of the architecture should be positive.

I suppose on Philosophical perspective you can think of Enterprise Architecture along the same lines as Darwinian Evolution. Put the right building blocks in place upfront, and the entity will have a good chance of survival.

So, design in terms of the core principles and building blocks should take place, however, don't over design as this may constrain you long term, remember, none of us know whats going to happen in the future, and my experience is expect the unexpected!

One of the key issues to consider is the cost of getting it wrong. The higher the cost of having to restructure the whole thing the more effort needs to go into planning up front.
Consider the key message from Agile Development: "build the simplest thing that can do the whole job, and emphasis is on whole' (maybe I don't recollect the exact wording here). Even for something that is considered very evolutionary, the basic architecture needs to be right up front, or you're going to hurt later on.
There is no conceivable reason to discard what is known and make your architecture too simple, or impossible to scale or what ever you know it will have to do.
That said, you can often create your architecture such that it is extremely scalable, but not implement the scaled out version from the start.

To change your architecture (not your implementation details) usually requires a major rewrite of everything. As long as the cost is small enough, do it, but as the project / system grows, the cost of doing this also grows...

What's a great elevator pitch for Agile?

colart@gmail.com (Colart Miles) — Sun, 07 Dec 2008 07:40:00 +0000

Let's say you got into an elevator with a senior executive and you had 30 seconds to sell Agile to them, what would you say?

B.T.W. This is commonly referred to as an elevator pitch and here's a good intro from Business Week.

Here are some answers I got back from the LinkedIn community:

Carolyn Sanders wrote:

"I actually do get asked this one by execs. This is what I usually say: Agile delivery is about two things: you usually don't know what you want until you see something, so deliver something real as early as you can; and if you're going to fail, fail fast. Agile in general is about being fundamentally honest with each other, about money, about technical delivery and quality, about requirements andtime - that's why it's so scary for some people."

Matt Richards wrote:

"Agile software development practices will give you more control over the cost and feature set of your software than traditional methods. You are also likely to have usable software sooner."

PJ Srivastava wrote:

"Are you at all worried that your project might go over-budget, that it might run behind schedule, that the customer might not like the end result, or that someone will change the project requirements on you in the middle of it? That's where Agile comes in. Its as simple as this: the more complex, the more challenging, and the more uncertain your project, the more you have to inspect it frequently and the better you have to control your process to be successful with it. Agile is simply a more intense, but tried-and-true process for reducing risk and better controlling your results. Give me 10 minutes of your time and I'll explain why some of the most recognized companies in the world are turning to Agile..."

What is the most important characteristic in an e-shop's web page?

colart@gmail.com (Colart Miles) — Mon, 24 Nov 2008 05:40:00 +0000

When you visit an e-shop's website, what is the most important characteristic(ex.: customer reviews, wizard tool, security, many payment methods, etc.), according to you? What is the one thing that will make you trust and buy, or come back to that specific e-shop, or what you are searching for?

This was selected as Best Answer

Great question! You would be surprised how many outfits set-out without considering this topic first so you're already at the head of the pack!

Here's my two cents worth:

Walk a mile in your customer's shoes... create a few persona's that model your typical target audience... bring them to life (like soap opera characters) and role play their experience when using your site. Better yet use these personas to look at your competitors sites. The objective being to uncover deeper insights into the design features that are most likely to win your target audience. The next and arguably most important step is to implement your e-shop with the intention of changing it in response to customer feedback. Get your site into a low-burn experimental state... as you discover what really works invest those parts.

Your e-shop should evolve really quickly and effectively this way.

oh and one other thing... as your question suggested that you want to differentiate I would suggest you use the persona's to try out new features or user experiences... This way you can home in on the differentiations that really work!

Best Answers in: Business Analytics (1)... see more

The many modes of a Business Analyst

colart@gmail.com (Colart Miles) — Sat, 01 Nov 2008 16:53:00 +0000

These days, business analysts are plying their trade in increasingly diverse settings and are being pushed more than ever to add value at strategic levels.

Good analysts are showing their mettle by adopting a range of operating modes. Here's a list of the operating modes I've applied myself and observed in others:

1) Orientation Mode

This is where the analyst (or analytical team) gets familiar with the domain and the stakeholders. We expect to see a great deal of relationship building here paying particular attention to the 'agenda setters' within that domain.

What it looks like:

Relationship building.
Coffee meetings.
Taking a passive role in meetings.
Conversations over the drinks cooler.
Conversations with the movers (and the shakers).

2) Description Mode

An analyst in description mode is focused on describing the current state and the end game and ensuring this is communicated to everyone involved. This is where the vision is captured from the leaders and communicated in as many ways as possible. The aim being to prompt discussion at the tactical/operational level and help the implementers understand how the vision is different from the status quo.

What it looks like:

Taking an active role in meetings.
Relationship building.
Generating descriptions (proposals, business cases, high level conceptual states, GAP Analysis).
Presentations & workshops aimed at understanding.

3) Analysis Mode

This mode comes into effect when the analyst has a substantial amount of data to digest. This may be information captured from users, stakeholders, subject matter expects or even simply from themselves which needs to be analyzed and developed to address key questions.

What it looks like:

Taking a more active role during meetings.
Analytical Modeling, requirements analysis, gap analysis, impact analysis
Cogitating, thinking, mulling over...
Discussing with other analytical peers
Researching analytical methods
Testing of theories
Recreational activities (e.g. playing online games or lots of breaks)

4) Prescription Mode

Here the analyst has developed a strong sense of direction and needs to communicate this to the implementers (whether that be directly to the developers or the people who manage them).

What it looks like:

Thought Leadership
Setting the agenda
Influencing
Providing constant reminding of the destination
Monitoring progress
Isolating and correcting misalignment

5) Prediction Mode

This mode is underpinned by a significant application of analytical skill-set, estimation. Here the analyst aims to predict the outcome of various conceptual (or committed) paths. It is important to note that the quality of this activity plays a major part in supporting good quality decisions. Often projects live or die by the quality of estimation at the outset.

What it looks like:

Estimation workshops
Wideband delphi
Creating estimation models
Trend analysis
Data analysis
Impact analysis
Workshops

6) Validation Mode

In this mode the analyst aims to independently compare actual outcomes with the outcomes envisaged to validate progress or delivery. This mode also aims to test the usefulness of what's been delivered as perceived by the user or customer.

What it looks like:

Test strategy formulation
Test design
Testing
Quality Assurance activities
User Acceptance Testing
User Calibration Testing

Plan to succeed on projects (Part 2)

colart@gmail.com (Colart Miles) — Mon, 22 Sep 2008 21:04:00 +0000

Now that you've planned the flight... Fly the plan.

If you've taken the advice given in Part 1 you should be set up to drive your projects by result rather than activity... you'll find your team responds best to this approach...

I posed a question on LinkedIn recently to see what advice the professionals would give a budding PM:

"What are the top 5 tips you would give a PM to improve their luck on projects?"

I chose a couple of these answers as they sum up the basic principles of flying the plan nicely:

Here's the answer offered by Gianluca Bacca:

1) Define the scope of you project as clear and as soon as possible and formalize it … a project doesn’t exists without a Project Charter and a WBS!

2) Be realistic and pragmatic, don’t forget that generally available resources are limited … a request or change coming from a stakeholder, generally, involves a trade-off between different elements of the “triple constraint” (time, cost & quality) … think always in terms of trade off between the elements of the “triple constraint”.

3) Manage ALL your stakeholders with care being proactive: to do this you need to identify ALL of them and constantly communicate with ALL of them

4) Identify all risk of your project and constantly looking for their evolution along the entire lifecycle of your project … don’t forget risk! In Project Management luck and bad luck doesn’t exist (more or less) … there are mainly identified and unidentified risks! Identifying risks you can build your luck by yourself ;)

5) Don’t forget to collect lessons learned after each project … you cannot improve your ability to manage your future projects without lessons learned from your past projects ;)

This is my favourite answer from an old colleague, Gunveer Mahandru:

1. Show leadership (strong vision, direction. take risks, manage them)
2. Develop a backbone (back up what you say, don't wilt and wimp)
3. Work the team dynamic (manage the form/storm/norm/perform phases)
4. Engage stakeholders and keep buy-in (politics with a small 'p')
5. Inject entrepreneurship (excite, motivate, innovate)

Short, sharp and very effective...

Here are a few more useful little project tips:

Derive a burndown chart and use it to generate momentum and track progress.
- use Mike Cohn's estimation technique, planning poker.
- derive the ordered stack and begin plotting this over the time line.
- You may want to include checkpoints (or iterations) in the plan. (Step towards Agile)
- use these checkpoints as opportunities to deliver value (no matter how small) and plot your position on the burndown chart.
- Remove products from the stack when considered 'done'.
- 'Done' = when someone other than the developer (preferably the recipient) says it is... i.e. it meets the predetermined acceptance criteria.

In fact, I'd heartily recommend you watch Mike's YouTube clips on Agile Estimation: Part 1 and Part 2

A short note on lightweight reporting:
Agree a '5 minute emergency channel' with the sponsor... As you become aware of an issue which significantly affects the project, present what you know to the sponsor (no interpretation) along with a few proposed next steps. Aim to present and get a decision within 5 minutes... Even if the next step is to have a longer meeting. This way you keep your sponsor in touch.

Good luck!!

Plan to succeed on projects! (Part 1)

colart@gmail.com (Colart Miles) — Mon, 22 Sep 2008 20:47:00 +0000

You've heard the old saying: "Plan the flight then fly the plan..." well I'd like to apply this approach to project management in this article and offer an formula that will ensure you're driving the project by result rather than activity.

Here we go:

Step 1) Find a sponsor. Note: If you haven't got a sponsor... get one... don't give in to the temptation to implement your own vision. If you're the sponsor then ideally get someone else to deliver your vision ;-)
Step 2) Talk to the sponsor about their dream... replay your interpretation at every opportunity. Especially the benefits they expect.
Step 3) Once you've gained a bit of rapport start talking about: scope, success criteria, time scales.
Step 4) Go away and think about the objectives and resources you'll need.
Step 5) Propose the set of highlevel project objectives and negotiate for resources.
Step 6) Develop a product breakdown structure... Derive the Product Flow Chart that follows.
Step 7) Market this to the team and sponsor as the delivery roadmap, make sure the roadmap attacks the highest risk/reward items first.
Step 8) In closing, make sure you're set up to drive the project by result not activities!

By this stage, you should have enough to get a green light to proceed. So there you have it... the flight plan.

In part 2 we'll look more closely at flying the plan...

Vendor Selection Tips

colart@gmail.com (Colart Miles) — Tue, 26 Feb 2008 20:45:00 +0000

What's a reasonable vendor selection process?

Selecting the right vendor starts with knowing what you want and then finding the supplier that will get you what you want. Here's a breakdown of what this might entail:

Step 1) Understanding the requirement
Step 2) Generating the options
Step 3) Analyzing the options
Step 4) Selecting the best option
Step 5) Getting the decision to proceed

Informal vendor selection (Fast track)

Use this approach if you need to turn around a decision really quickly and you have the remit or necessary sponsor support to keep it informal.

Step 1) Understanding the requirement

It's pretty important that you have an idea of the desired outcome before even considering vendors. A standard gap analysis is a great approach to getting to understanding the problem. Work out where you want to be (i.e. the end state) make sure it's ecologically sound. That is to say that the outcome is beneficial in some way to all concerned! Invest the time to articulate exactly what you want in the form of a problem statement(perhaps reinforced by a statement of what you don't want). The principle being that your chances of getting what you want dramatically increases if you know what you want ;-). It helps to use the problem statement to identify your selection criteria (see Step 3 below)

Try to have the target budget identified. This may need to be challenged later depending on the criticality of the desired outcome.

Step 2) Generating the options

Use your problem statement (created in Step 1) to identify possible vendors. You may want to contact your procurement department to check whether they have any preferred suppliers to hand. (Note: You may need to be sensitive to existing supplier relationships). The next stop should be your immediate professional network followed eventually by speculative internet search. Generate the list of potentials bearing in mind that time is of the essence.

Contact them by phone at first to weed out the obvious mismatches. Once you've got a short list together send them your problem statement via email (or mail). Follow this up with a phone call explaining your time constraints and openly request their support. Be sure to share any information fairly across your vendors. (e.g. an answer to a question may need to be shared with the other vendors)

Set-up a demo day for all your vendors.

Step 3) Analysing the options

Invest in getting a few key assessors together that will balance your judgement. The pay-off will be that your selection is less likely to be overturned later on. These additional perspective will ensure that your blind spots are covered.

Create a score card with the selection criteria down one side in rows and the vendor options in the columns for assessment. The intention is to score each criteria out of five for each vendor (where 5 = 'excellent fit for purpose' and 1 = 'unfit for purpose').

Apart from the usual logistics (meeting rooms, diaries etc.) make sure you have briefed your assessors on the problem and the instructions for filling in the score cards.

Step 4) Selecting an option

Make sure the vendor demonstrations focus on addressing the problem statement. Collate the score card results. Add the scores up for each vendor and calculate the percentage of the maximum available. You can express this percentage as 'the estimated percentage match to requirement'.

Offset these percentages against the cost profile for each vendor. Try to identify the vendor with both the highest percentage match and the lowest price.

Discuss your findings with the other assessors (make sure you have consensus).

Step 5) Getting a decision to proceed

Present your findings to the decision maker(s) along with your recommendation. Make sure the next steps are agreed (i.e. what you need from them to proceed) this could be an authorising email or Purchase Order. This will depend on the Inform your vendors of the outcome and try and provide as much feedback as possible.

In part two we'll look at fast tracking this with little more formality.

Tips for buying a business.

colart@gmail.com (Colart Miles) — Fri, 20 Jul 2007 13:49:00 +0000

What criteria would you use to assess the value of a business you're interested in purchasing?

I heard a recent suggestion that the value of the business begins at zero and every Pound/Dollar above that needs to be justified by the seller. This paradigm shift puts the buyer in a powerful position to negotiate.

Here are my thoughts on factors that would make a good business buying opportunity:
1) Low asking price in relation to comparable businesses. (i.e. Low investment with high potential)
2) A sound business model that has the potential to generate repeat customers.
3) Depreciating fixed assets represent a small proporation of the overall investment.
4) The seller lacks confidence in the value of thier business (sometimes exhibited by a poorly run operation) This will tend to represent an opportunity to quickly add value once purchased.
5) Good management structure.
6) Enormous unrealised potential.

Those are my thoughts... What are your top buying factors?

BTW: here's a great resource if you're considering buying a business: Business Link.

How to generate better luck on large projects.

colart@gmail.com (Colart Miles) — Sat, 02 Jun 2007 12:25:00 +0000

Today’s topic will include a look at typical project cycles and how to dramatically improve the 'luck' experienced on a project.

This posting focusses mainly on the Start-up and Final Delivery phases of a typical project and answers the question: What can we do during the start-up phase to promote success during the final delivery?

We will approach the answer by first looking at the 'What' and 'Why' before moving on to the 'How' and 'Who'.

So lets get started...

How can we generate better luck on our projects?

Step 1. Make sure you have the end in mind before you start.

Identify the high-level project deliverables along with the main business drivers. (Business Case)

These are powerful navigation tools essential for steering the right course.

Conduct a study of who your Stakeholders are and what benefits they'll want from your project.

Meet with your customers and ask them to help you to help them. Sounds cheesy, but it's a great way to build rapport and calibrate your approach. This will also demonstrate to them that your project is focussed on delivering benefits and not just another sterile solution.

Develop an 'Elevator Pitch' for the project and have this adopted by your management team.

Create a detailed Product Breakdown Structure taking into account the stakeholder input.

This takes care of the ‘WHAT’ and ‘WHY’ for your project. Now let’s look at the ‘HOW’ and the ‘WHO’...

Step 2. Conduct a full inventory check on the resources you and your team have at their disposal:

People, skills, expertise, budget, time, infrastructure, sponsorship support etc.

Consider the timelines for when these resources may actually be needed.

Assess any gaps between the project demand profile and what you can supply in terms of resources.

Work out how to fill the gaps. For example request more funding, skills etc. This is where you show your initiative and resourcefulness.

Step 3. Measure Measure Measure !!!

There's an old saying: "What doesn't get measured doesn't get done."

How will you know when you get there?

Look at the Product Breakdown Structure and work out ways in which to measure the successful delivery.

Carefully decide on the quality criteria for each one.
Try applying the GQM method to get started.

Make sure they are SMART criteria.

There is a strong cause and effect relationship between the decisions made at the start of a project and the ease of success of the output.

In short, effort invested in these techniques at the beginning will amplify the luck experienced at the end.

All the best,

P.s. Feel free to comment on this blog with your own experiences.

Make your mistakes early and cheap!

colart@gmail.com (Colart Miles) — Wed, 23 May 2007 11:46:00 +0000

Take too long to deliver and you've missed that crucial window of opportunity!
Someone else gets to market with a competing product and again you've missed the boat!

This is where we can learn from today's entrepreneurs...

*** Make your mistakes early and cheap ***

(Featuring: Five easy steps to consider when planning your next deliverable ;-)

Last year we had a brand spanking new product to launch for a rather large internet start-up that sought to combine three major technologies; Mobile, IM and VOIP. The sheer volume of assumptions we were relying on made management very nervous. Their (quite natural) response was to consider extending the deadlines and increase quality control. Luckily, we managed to convince them to support our, seemingly counter intuitive, approach...
By thinking like a garage start-up we aimed to capture the essence of the business model in a cheaper and simpler solution. We found we were able to gain faster access to the revenue, drastically reduce the time to deliver and minimize the associated risk exposure. We planned several incremental releases that would respond to the feedback captured on the fly. This enabled us to maximize the revenue streams and easily ramp up the complexity. Working closely with these entrepreneurs gave me the idea for this post:

Here are five easy steps to applying the entrepreneur's lesson to your next project:

Step 1) Analyze the core requirement that your deliverable is addressing.
This is very much about WHAT your deliverable is trying to achieve as oppose to HOW. The answer will give you greater flexibility when generating pilot options.

Step 2) Conceptualize a Pilot version of your deliverable that meets this requirement.
As a rule of thumb, aim to scale the solution down to about 25% of the original budget.

Step 3) Plan to pilot this release to a select set of target users.
Identify and engage your customers early. Prepare them for the release and how they can best help out. Make sure you establish several ways for them to communicate with your team.

Step 4) Set-up your development resources to respond quickly to feedback.
Make sure your own team is setup to capture and manage the changes in the following releases.

Step 5) Start planning a series of releases as required.
Be ambitious with your delivery dates. Constantly re-prioritize the tasks to maintain alignment with the overall requirement. Think Triage! Follow this up with a schedule of release dates and commit to them publicly.