Craig Brown

Evaluator

My business is called Evaluator.com.au. Not only do we evaluate your performance against a range of business and technology standards, we can help you grow and improve.


Even though I am based in Melbourne we can help you anywhere in the world.

Posts

May 17, 03:00 PM

As a follow up to this video on the optimism bias, I thought I would add a few comments.

Tali's hypothesis is that optimism is a critical element of success. Without optimism we'll just give up, or not have faith we can overcome the challenges that beset us. So optimism is a net gain for the human race.

On the other hand, optimistic estimates make us fail.  We fail because we set unrealistic expectations and thus when we deliver, we let people down.

It's a conundrum. How do we optimise delivery by taking advantage of our natural optimism, and still avoid over estimating our ability to solve the problem?

Some solutions that have been tried in the past include;

  • Separate the people who do the work from those who do the estimates so you can bypass the optimism in the team
  • Ensure your team has pessimists on board so that they can speak of the worst case, bundle this with blind delphi estimates
  • Force thinking by the team about best, likely and worst case through scenario modelling, and weight the estimates with historical performance or arbitrary numbers
None of these work particularly well.

Our preferred method today is to use historical data. And if we don't have some, to work in small bacthes until we do.

The jury is still out on how we budget for the rocket to Jupiter.
May 16, 08:00 PM
 According to the meetup group we played with the other day it is paper prototypes.  
(You can see the whole list of techniques we discussed here, and the game we used to create the list here.)
Ideas for DarkPatterns.org homepage

What we the criteria that got it up as the champion technique on the night?
  • You can test business ideas with them
  • Paper prototypes can be built quickly and edited just as quickly
  • They can be disposed of equally quickly and with less fanfare than the deletion of an exquisitely crafted Balsamiq wireframe
  • Pictures tell a thousand words
  • Screen sketches capture key business data
  • Screen and flow sketches capture important process and interaction flows
  • The combination of the above help you discover edge cases
  • A paper sketch doesn't get you caught up on details of design or UX
Here are some handy resources on Paper Prototyping
  • Wikipedia page
  • A case study on designing a University web application
  • An online book - Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces
  • A handy Youtube clip showing someone do it particularly well (embedded below)
May 15, 08:50 PM
I've posted about him before, but if you're not reading Jeff Atwood's Coding Horror blog, you're really missing out. Today's post is perfect. There are several lines that really stuck with me, here is one of my favorites:
Please don't advocate learning to code just for the sake of learning how to code. Or worse, because of the fat paychecks.
Over a year ago, in response to one of my posts here on the site, someone told me that if I didn't like how developers did their jobs, I should go out and write the code myself. The idiocy of the statement just astounded me. Now, here is one of the premier programmers in the world, backing me up.

You see, learning to code is very similar to business analysis or project management. It may sound like something that anyone, given a weekend and a 'Teach yourself XXXXXX in 24 hours" book can do, but learning a programming language does not make you a developer, nor does learning the concepts behind business analysis or project management make you either one of those professions.

My biggest concern is that most everyone should not learn these skills. To quote the movie Tommy Boy:
Tommy: I can get a good look at a T-bone by sticking my head up a bull's ass, but I'd rather take a butcher's word for it. 
Most business people shouldn't need to know more than the basics about technology and they definitely shouldn't know enough to try doing project work, at least not beyond being a SME. Its not that these people are dumb, far from it, but their expertise is in running the business. Those of who work on projects, developers, analyst and PMs, have our areas of expertise as well. Some of the skills overlap, but lots more do not.

With my background as an analyst, I do tend to see everything through that lens. When I'm in a meeting to discuss a recently discovered problem or opportunity and the first thing I hear is someone say, "What we need to do is..." I find myself trying to breathe deeply and not lose my temper. Starting at the solution without really getting a firm understanding of the problem is one of the worst mistakes you can make when doing analysis. It is a very easy failure to make, one I see analysts make regularly, but one that you have to train yourself out of in order to be the best at what you do.

Be an expert at the things you're really good at and leave everything else to the experts in other fields. When we work together as a team of experts in our own field, we do better than a bunch of amateurs who don't know enough to know they don't know what they're doing.
May 15, 09:24 AM

"Are we born to be optimistic, rather than realistic? Tali Sharot shares new research that suggests our brains are wired to look on the bright side -- and how that can be both dangerous and beneficial."

May 09, 08:26 PM
I regularly read Rands in Repose, and today's article was nothing short of awesome. If you're not a Rands reader, I highly recommend you become one, if for no other reasons, for bits like this:

Photoshop’s goal isn’t entertaining unless you think the national pastime of bitching about Photoshop is a sport. Photoshop has no points or leaderboards because Photoshop is a tool and the perception of tools is that you must be willing to supply blood, sweat, and tears in order to acquire the skills to become any good at using them.
Bullshit.
Make a list. Tell me the number of applications you use on a daily basis where there is a decent chance that you’ll end up in a foaming at the mouth homicidal rage because of crap workflow, bad UI, and bugginess. Is Photoshop on that list? Yeah, me too.

Photoshop isn't one of my regular tools, but the Mac image editing app Pixelmator absolutely is. Why? Two reasons... first, its slightly cheaper and second, it doesn't make me want to gouge my eyes out every time I open it. No, I'm not a professional image editor, so I don't need Photoshop, but the few times I've tried to use it, I run screaming back to Pixelmator every single time.

I bring all this up because I feel that programs like Photoshop just need to die. Die a horrible death. In a fire. Then get its ashes buried in the deepest part of the ocean. Never do we want to involve ourselves with something that makes our users want to hate our product. This is a sign of a product, and the project that creates it, gone wrong.

Oh, and before I forget, there are a few other apps that fit on my 'list' as well. Naming them all would take too long, so I'll list categories instead, but I bet your list looks a lot like mine:

  • Microsoft Office
  • Project Management apps
  • Requirements Management apps
  • Defect Tracking apps
  • Testing Automation apps
Pretty much, if its a tool used by project people, I'm probably going to hate it. That's sad, because in the 10.5 years I've been doing this, it hasn't gotten any better.

(Yes, there are some fine tools out there; I just don't get to use them, and even those I have played around with that were not terrible still made me want to gouge out my eyes at least once a day because of some insane thing it did.)

What's on your list?
May 09, 07:17 PM


It's time for us to refresh the tone and content here and so we would like to hear from people who would be interested in joining Ted, me and the occasional other to blog here.

The rules are pretty simple; share what you are learning as you grow in your role.  Get in touch if you are interested and we can talk more.

May 02, 07:00 PM


Being agile is not always important.

The interwebs have a thing going on in recent months about the difference between doing agile and being agile.

There are a bunch of agile things that correlate with positive business outcomes, but they aren’t universal are they?

I work at a university. What we do in the IT Department is important but it is barely core business.  Core business for universities comes in three forms; Innovation borne out of research,  student experience, and subordinate but critical to that; teach experience.

A side note on that topic: Research and student speak for themselves. That’s where the money comes from, either directly or through government grants.  Teacher experience is worth noting because most teachers in universities are working at below their market value.  For example, all of the teaching staff related to ITC that I have met at Swinburne are smart, pragmatic and well informed in our industry. They could all be earning much more as consultants and industry practitioners. But they sacrifice earning more money in order to be able to participate in the shaping of the industry both through research and through teaching students.  There is clearly consideration in that.

Back to being agile.  What can the IT Department do to affect these three aspects of the business? Yes there is a place to play in making commodity systems (mostly procured, not built) work.  And yes, if they don’t work it can be a big deal.  So you need to be capable at managing commodity services.

Where does being agile play into that?  Where is the need for responsiveness to market conditions? How does an effective IT department affect enrolments or staff engagement?

It doesn’t really does it?

Yes, it will. When traditional education starts to feel the effects of the current and next waves of industry disruption technology will matter.  But it probably won’t come from the OT Department. Instead the fancy innovations will be business led, often with IT partners outside the organization.

IT will still be important, but it will become a hygiene factor rather than something that gets discussed at the University Council.

And so, while being competent matters, being agile doesn’t.  

So why pursue agile practices?

Perhaps because they might become table stakes for being competent.  Perhaps because IT will partner with the business in innovation and industry disruption (They are probably as good if not better than many IT partners universities work with.) Perhaps because, as a developer led movement the agile values and ways of working are imbued with respect for the workers.

Perhaps because, once you understand it, you realise that working in more traditional command and control modes is fundamentally stupid. Enabling people to do their best is a much more savvy way t do business than managing to the lowest common denominator, or trying to manage away all risks through mandated methods.






May 01, 09:39 PM

Agile Business Analysts

A Melbourne community meet-up group 
invite you to

Fight! The ultimate BA technique 

Tuesday, May 8, 2012, 6:00 PM 
Microsoft office, LVL5, 4 freshwater place, Melbourne 

At this month's Agile BA meet-up we share our favourite techniques and search for the ultimate technique - that's right; the one method to rule them all!



Approach 
We will do this via a game. Teams will form and share their favourite techniques and methods, with examples of where they have been successful.

Teams will then pair off against other teams and present their favourite methods and challenge the other team with counter examples or questions. The rest of the room vote on the winner. We repeat this in a series of four to five rounds until a winner is found.

Along the way we hear lots of examples of where analysts have deployed successful techniques and hear what situations they may not work in as well.

Learning Objectives 
This is a fun interactive way to review a broad range of methods and techniques, to talk about them, and hear stories of when they have been successful in the field.

You bring
Your variety of experiences, an inquisitive mind and a pen and paper. Post it notes would also be good 

Audience level 
All levels of experience are welcome. Diversity of the whole room is what is most important. The call to action

April 29, 07:00 PM
April 26, 01:30 AM
Ed Wong is one of the organisers in the local meetup community.  He's passionate about helping teams adopt agile practices, design user centric products and helping others learn.  After going to the Agile Tour event in Sydney last year he returned to Melbourne with the idea that we run something similar in Melbourne.

I argued that we extend the scope a little and we came up with Lean and Systems Thinking as two additional themes we should include and that led naturally to LAST as an acronym. When we discovered LASTConference.com was available as a domain we settled on it pretty quickly.

The biggest deal when arranging things like this is arranging a convenient venue.  Fortunately I am working at a University.  I went to the faculty of ICT and asked whether they would be interested and of course they were, so we scored a win by being able to host our event at Swinburne on July 27th.

Next we started asking Australian agile, lean and system thinkers people if they'd be interested in participating and several generously said yes instantly, and while we have not yet settled on the final line-up we can rest assured that we will have at least some interesting and engaging people facilitating sessions on the day.

Right now you can see some of the submissions on the LASTConference.com site, and you can also read more about the details of the day.

Our event is not designed to compete with Agile Australia. It will be more grass roots, led by practitioners and designed for practitioners.  There will be no big names from overseas and no CEO perspectives.  But it should be a fun day.  If you are going to be in town, come along.

(A last note, Rowan Bunning contacted Ed a few days ago and let us know that Simon Bennett is a Lean/Agile/ST coach and consultant in the UK trading under the name LASTing-Benefits. We don't know Simon, and are not directly associated with him, although I have discovered him in my Twitter feed. It's a small world isn't it.)
April 23, 07:00 PM
Almost 1 year ago, I wrote a post about using Google Docs as a requirements documentation and management tool. Since then, we've finalized requirements for our first project phase, have made it maybe half-way through development and have even done a little bit of testing.

I thought this might be a good time to update everyone on my 'little' experiment (I'm piloting this on the largest project my company has ever done, thus the quotes around the word little) as I now have a better understanding of what worked well, what didn't, what sank like the Titanic and what I think we'll do different next time.

The Good

Believe it or not, there really were a LOT of good things to come out of this test of mine. Here's a little list for handy reference:
  • Speed of revision. Like any project, especially one where we started the requirements a long time before the development, we have had to make adjustments along the way as what we thought would work well sometimes ran into the wall of technical limitations. Because we didn't have an architect or developer reading along as we wrote the requirements, we sometimes failed to get down to the necessary level of detail for the developers to get things right.
  • Collaboration. Everyone has access to the documents. Everyone knows where they are (or at least they have been told!) Everyone can go look at them and ask questions. They are not buried on some shared drive that is only accessible when at the office or when connected over a VPN. If you need them, they are there.
  • Prototyping. Using Google Drawings to create wireframes makes getting ideas in front of our customers insanely easy. We have built a set of stencils over the last year or so that make drawing  and sharing a new screen idea trivial. This alone has saved me an insane amount of time.

The Bad

I wish it had all been good; I really do. Here's a sampling of feedback we've received on what doesn't work so well.
  • Too many docs, too many places. This one I actually take issue with, but it has been a consistent piece of feedback from the developers. They don't know where to look, despite having divided all the documents up by subject matter separate collections. There have also been complaints that we spent too much time categorizing information into different document types and not enough time tying all the document types together.
  • Google Docs sucks at formatting. Well, this one I completely agree with; it really is terrible. Thankfully, we are doing a minimum amount of formatting, so the pain isn't horrible.
  • Google Docs sucks for large documents. One document that the development team demanded we create, against my better judgement, clocked in at over 300 pages (long story; shoot me before I ever agree to this again). You can't use the revision history functions; it locks up. Loading the document up in the browser maxes out your CPUs for a very long time. Keep your documents simple; you will not regret this.
  • Speed of revision. This could probably be said as a bottleneck in our review process, namely finding time for me to actually look at and approve the changes. My BAs are awesome, so awesome that with all my other duties, finding time to review their changes, even small ones, is a big challenge. Thankfully we keep a fairly detailed change log so I know what documents need reviewing.
  • Collaboration. Some people just didn't get the concept of a document as a living thing. A few times, we had developers show us printed copies of docs that were 2 months out of date and try to claim things they coded in the last week didn't match the document. True, it didn't match the printed copy they had, but it perfectly fit the current one that had been updated prior to the start of their coding. It took several rounds of this happening before the dev team finally believed us that working from the online docs was the best thing.
  • Mobile. I live on my iPad. It never leaves my side. Google's support for it is horrendously bad. Drawings appear as an ill-formatted and shrunken image. Text documents only have the most rudimentary editing support. Spreadsheets... just don't bother.

The Future

We are about to start putting together some ideas for the second phase of the project. We want to build upon the good start we have with this tool and figure out ways to make this process work better. This project (really a program) is going to last for a few years as we replace and revamp our processes and systems from the ground up, so this is something we'll need to make work well. Here are some of the changes we're considering:
  • Omnibus Documents. Instead of 4-5 different types of docs, we are probably going to merge all docs for a particular subject area into different pages of a spreadsheet. While this makes the issue of document size all that much worse, it will (hopefully) make understanding what to read easier on the development team.
  • Better collaboration. This isn't so much better about where the documents are housed as it is about having the development and testing teams involved earlier in the requirements process. This lack of involvement in the first phase has been one of the largest hindrances during the project as it has caused a significant amount of rework. The BAs are not developers nor are they testers and expecting them to capture everything the other teams need without input from those teams is just not going to work.
  • Expanding the use of the tool. Google recently announced that teams can use Google+ Hangouts with Google Docs. For our offshore team, this would be a great way to review documentation prior to any code being written.
So what new types of requirements solutions have you been working with in the last year? Drop us a note in the comments!
April 18, 08:23 AM

If you have been watching my tweets you'll notice I have been searching for any reliable evidence that Prince2 as a method has delivered any sort of possible results to users.  While there are anecdotes of project managers describing success with Prince2, there is no evidence that it is anything more than a coincidence.

Apart from asking practitioners on PM forums and social media, I have also searched industry and academic papers on the topic. Nothing.

So, I am now confident to say that there is zero evidence that Prince2 can help you achieve any sort of success.

You would expect what people have invested in it, there would have been some work invested into proving the model. Given it isn't there, even in a tenuous, challenge-able state, I have modified my hypothesis.

My new hypothesis
"Prince2 actually contributes to cost over-runs, budget crises and disillusioned clients."
I don't know that this is a truth, but I suspect it is possible.  For example, we find Prince2 concentrated in UK and Australian Government circles. Coincidentally these domains have a reputation for poor delivery, bad project choices and tremendous amounts of waste within their projects.

(And yes, there are plenty of exceptions, but there is a clear trend, you have to agree.)

So, the call to action:  Can you help me prove or disprove this hypothesis? Do you have any studies or reports that cold help?

Things that could be useful;

  • Reports on industry project performance correlated to industry Prince2 concentration
  • Surveys of project outcomes compared to project delivery methods
  • etc
Looking forward to your help :)
April 11, 09:00 PM
Left to right: Me, Annie, Trent, Paul, Kaye, Erik,
With Kevin standing, possibly about to throw something at us.

On Tuesday night the local business analyst community met up to hear a debate facilitated by Kevin Broughton.  The topic was "Business Analyst: Role or Competency?"

We had 5 great panellists, and me as a ring-in.

On the pro-role side there was Paul Velonis and Erik Van Eekelen from Elabor8, Kaye Knight, contracting analyst gun for hire, and Trent Barnes, a recruitment consultant who specialises in BA, PM and QA roles from CicuitIT.  On the pro-competency side we had Annie McGlade, a BA Competency Lead at a large bank and myself, a natural contrarian.

Given the audience was a bunch of business analyst (peppered with a few analyst programmers) the debate pretty squarely landed on the side of "There is a clear need for business analysts, s don't be quitting your day job just yet."

Let me see if I can summarise the arguments in the order they were presented.  I'll make a few mistakes because (as a ring-in) I was trying to work out what I was going to say while they were taking.  I'll editorialise as well. Maybe the guys will drop in some comments below.

Paul started with the disclaimer than analysts are probably not required on small development initiatives where there are 2-3 people on the team and a single customer.  Things are straightforward and the communication lines are simple. Assuming your developers are competent and your customers knows their business and has some sense of the market they are working in you should be okay.  But, as soon as you start to scale - either in team size or project complexity a business analyst becomes a highly valuable asset for the team.  Systems thinking, asking 'why' a lot, and helping people deal with complexity were just a few of the issues he said business analysts were useful for.

An interesting note Paul made when speaking was that Elabor8 analysts were all trained and coached in consulting skills, and the 'business analyst as consultant' very much flavours the way he sees an agile BA working.  [Craig editorial: Me too, by the way.  Facilitation rather than system analysis and modelling skills are clearly the more important skill for an agile BA.)

Erik followed up (or was it Kaye next?) with examples of how analysts add value.  Essentially he amplified what Paul was saying, and expressed a caveat on Paul's idea of small teams not needing analysts, saying that while they may not need one, an analyst can usually help a lot even in these situation.  A key part of Erik's argument was that he believes that the members of a multi-disciplinary team should help each other out to get their stories done, but that that every discipline (BA, test, dev) demand its own, very specific, skills to do the job properly. That's why he said that any Agile team - no matter how small- should have a BA, a Tester and a Developer: it takes skill to play each specific role.

Kaye introduced the Swing picture below and talked about the need to continually ask 'why' and to seek out answers to questions and to challenge assumptions. She also highlighted the analysts ability to think about the situation independent of technology, and thus help with customer centric thinking on the team.


Next up was the other side of the argument; The analyst role is not needed on agile teams, and all that is required is the competencies.

Annie went first and talked about how any person with sufficient motivation can be trained and coached to perform the role well. And conversely that many people in the industry operating with the BA job title were not actually adding a lot of value to the teams they were on.  She also made the point  that job titles come and go, but it is the tasks, activities and thinking tools that are required for teams. Who has them doesn't matter so much.

Lastly I went and my argument was that hand-offs degrade flow and that applies just as much to project teams as it does to organisational silos.  As a bunch of analysts, I sad, we are all familiar with the boundaries on swim lanes being obvious pain points. (Erik and Kaye countered me with the surgical team metaphor. A bunch of specialists working as a team are still specialists.)

I tapped into the emotions with two stories:  Firstly, when doing some BA competency assessments I didn't see strong correlations between effectiveness and competency. What was much more important for team effectiveness was playing as a team.   And secondly I saw an example of a team where a BA became a single point dependency, and when they were away the team crashed. But that crash and absence was a catalyst for further improvements from team outputs. (Of course I was playing a devil's advocate and Erik once again called me on the anecdotes != statistics rule.)

The debate was interesting and fun. We explored a few ideas, and had a good Q&A session afterwards.

A few closing notes because I wanted to say this but forgot on the night;

  • The only Agile model that is dogmatic about roles is Scrum. Everything else pretty much accepts whatever your current staffing model is, with the caveat that the team should work together as collaboratively as possible.
  • It strikes me that the emergence of the BA role was in response to a need for a generalist to act as a boundary spanner across the organisation. With the IIBA doing a very good job of defining the role, with it's boundaries (i.e. a BA is not a change manager or trainer) they are going to create a vacuum for  that generalist role and something else is possibly going to have to take it's place.
So, I'll leave it at that.  If you were there I'd be keen to hear your thoughts on the night.

March 31, 07:02 PM

Insight,
 delivered to your mailbox/RSS feed/Twitter account/Facebook feed/Google+ account three times a week, every week.


March 28, 07:10 AM

The Community of Practice is a concept that is used in professional and corporate circles to describe a community of people with common areas of interest, mostly in relation to the performance of role oriented tasks, but sometimes more generally. Ideas that underpin the Community of Practice include the concept of self-directed learning and knowledge sharing through storytelling, and collaborative problem solving.

The community of practice is manifested in work environments I attend through activities such as brown bag lunches, CoP monthly meetings, shared online spaces (such as a BA practice Wiki), Social media groups, on-line forums and so on. Communities of practice share many aspects of the master-Apprentice model without the formal hierarchical and power based roles inherent in the guild system. Communities of practice tend to be free and opt-in entities. People are typically free to join and leave when they want.

The community of practice is an idea full of contradictions; for example if it is voluntary and potentially quite ad hoc, how is knowledge on standards and quality developed and maintained? In this idea we find the challenges of creating and sustaining an effective community. People need to find purpose in participation, must find a way to both learn and contribute and must feel a sense of ownership in its success.

A Community of Practice is a difficult thing to make work over the long haul. A worthwhile consideration is; To what degree does this need to be a sustainable community? Is it still valuable if it comes, fulfils a need, and then once the need diminishes, the community disbands? This idea of a temporal organisation stands in contrast to the guild system, which like corporations creates an entity who’s main motivation is to sustain and grow its own power.

Given the CoP’s potentially temporal nature it’s worth considering the contrast with projects; CoPs don’t have a specific goal, and they don’t have a specific end date. While projects are typically led by a client’s vision, communities are led by an emergent vision from the group.

Given this concept fits so well with the idea of managing work in complex domains it’s surprising we don’t hear people talking more about leveraging Communities of Practice as vehicles for getting things done.
March 26, 08:59 PM


The History Lesson
A guild is an association of craftsmen in a particular trade (Wikipedia.)

 Guilds were usually organisations that had an early form of accreditation and membership, often in the form of something called “letters patents” issues by the local lord. The result of this is an exclusive right to deal in a particular area. The guild would charge members a fee to join, and in return members would receive a right to practice their craft within certain jurisdictions.

As ‘professional’ organisations members would swear an oath of allegiance to the guild, much like members of modern organisations like PMI sign on to an ethics standard that implies certain behaviours and allegiances to the profession above and beyond the guild members’ other obligations to the customers.

Guilds ensured their dominance over labour markets by ensuring certain quality and performance standards were met through professional standards and through the apprentice, journeyman, master model. This model had a variety of consequences including the control of labour which ensured premium wages for guild members, and eventually a proliferation of specialisations within the guild.

This fragmentation eventually led to the end of guild dominance of the professions, as subgroups competed for dominance in their market.

There is a general view that the guild was essentially a racket which stifled innovation and creativity within industries. It was a classic example of the status-quo maintaining it’s power rather than seeking advancement in skills and techniques that would benefit the industry and the community it served. Guilds primarily served their members to the disadvantage of both later generations and the community or customers they serviced.

The Guilds of Today 
Today many guilds still exist, especially in the creative industries. Some guilds wield large amounts of power, such as the groups that manage and protect the interests (including intellectual property) of writers and artists.

We can see that guilds can still be overly focused on the short term goals of protecting the status-quo over being responsive to future members and the communities they purport to serve.

Newer guilds (like in the software craftsmanship movement) don’t tend to have the tremendous amount of power and influence that large and established guilds demonstrate and wield, but they clearly have that tendency.

So when we talk about guilds in the software craftsmanship or IT domain what do we mean?

The term was pressed into duty because we wanted to draw on the strengths of the master-apprentice model. We want to acknowledge that the most effective way to transmit complex knowledge or knowledge of complex information is through mentorship, and oral tradition.

I have two questions out of all this;

  1. Are we stealing the word and re purposing it? Or are we in the business of building up a power base with a view to protecting member interests over the world around us? 
  2. Is the Master Apprentice model the best one for where we want to go, and are the assumptions that underlie it valid? Can you help?
March 26, 08:48 PM

Burn-up charts are different to burn down charts. They present different information and address different needs.  This post takes a look at the Burn-up chart and how it is useful for managing client and stakeholder expectations.

While burn-down charts are a team tool to help the team gather data in order to inspect and adapt within a sprint, burn up charts are about presenting data to stakeholders outside the team.

What is a Burn-up chart?

A burn-up chart is a chart that shows the rate at which features are completed over time, indicating when a particular parcel of work will be done.  Burn-up charts measure the work completed per iteration and provide empirical data to assist with forward planning.  The are similar but different to both Earned Value and Cumulative Flow charts.

Things a Burn up chart helps us understand include;
  • What is the size of the total work under plan?
  • What is the team’s velocity (i.e. capacity)
  • When will key releasable feature sets be reached?
  • What trends are apparent?
  • What problems or opportunities can a burn-up chart address?

Burn-up charts are a tool to communicate when the team think they will be done to project stakeholders
They assist in the planning of downstream activities such as advertising, release management activities, and other release to user type activities

What Burn up charts are not

  • Burn-up charts are not measuring work in progress or work completed within an iteration (see Burn Down Charts.) 
  • Burn-up charts do not measure activities completed. They only measure the completion of valuable increments of working product.
  • Burn up charts are not Earned Value Charts. For example, they do not measure expenditure.

Who is responsible for the burn-up chart?

The answer tot his question depends on the team structure and roles you have on your team.  The burn-up chart shows when releases or projects will be completed so ask yourself who is best positioned to manage this message.

Typically the ‘product owner’ will be the focus point of this sort of messaging, although it may also fall to a project manager.  Also, it is not unusual for scrum masters of business analysts to accumulate the data.

Consider that there are three aspects to managing this sort of reporting;

  • Create the report system via negotiating the data to be accumulated, setting up templates in excel or Powerpoint, or within backlog management tools and so on,
  • Gathering the data on a regular basis to support the report
  • Actually delivering the message and having the discussions that go with the report.

Strengths and Weaknesses of the tool

Strengths

  • It is simple to implement
  • The image trends towards an idea of 100% complete
  • It is a leading indicator – showing what the future is likely to bring
  • It presents data over time so systemic trends become apparent
  • Early stages of a team often present overly pessimistic velocity, which can cause anxiety in stakeholders
  • The binary nature of work – done/not-done encourages teams to manage their work to complete quickly

Weaknesses

  • Cumulative flow diagrams provide a more fine grained view of work in progress and bottlenecks
  • Burn-up charts require calculating velocity and story points which may or may not be valuable activities, depending on the team context
  • Teams that do not manage their work to a ‘100% completed’ state are hiding work which will surprise stakeholders later in the project.

Related topics


  • Cumulative Flow Diagrams
  • Release plans
  • Earned Value Management
  • Product road maps
  • Gantt charts

Further reading





March 21, 04:00 PM

When I talk to the local business analyst community about the User Story I always break into a little routine about how a user story is different and distinct from business analysis and requirements modelling.  My metaphor is the support ticket.

When a product support team receive a defect report they raise a ticket in their management system and do whatever needs to be done to resolve it.  The ticket travels through whatever workflow is appropriate to it and eventually someone resolves the issue, verifies with the customer that all is well and then closes the ticket.

Generally requirements analysis isn't really done. Certainly discovery work as performed in the BA community isn't done.  The support team tent to either know through their experience what business requirements apply to the problem area, or they look at the manual. Sometimes they may ask for clarification, but this is rare.  The team are expected to know how the system works and how it supports user operations.

This is not to say requirements don't exist. It's just that they are independent of the support ticket.

User Stories are like that.  They are the ticket that travels through a workflow.

(Of course I my model here is flawed. The "As a, I want, so that" strays into analysis and modelling territory addressing partitioning of work, user modelling, motivation modelling and even interaction modelling. But it doesn't do the whole job. Analysis and modelling remain distinct activities and artefacts.)

March 20, 07:52 AM
By my estimate there are four main schools of analysis;

  • Data Modelling
  • Business Rules Management
  • Business Process Modelling, and
  • Interaction Modelling (i.e. Use Cases)
We as a community of analysts tend to get early exposure to one and then work to master it.  And that works to a point because some disciplined analytical thinking goes a long way no matter how it is applied.

We then augment these basics with more advanced skills and techniques and complement them with social and interpersonal skills and gradually become highly competent analyst/consultants (and sometimes even an Analyst-Therapist.)

But.

Imagine if instead of investing all that energy into mastery of one modelling school we were to instead become generally competent at two, three or even all four?  By applying multiple thinking models to the problem at hand we will get a better and more broad understanding that we will from improving our artistry in techniques such as BPMN or Use Case Narratives.
March 20, 07:24 AM

Two Wordles comparing early 2012 BetterProjects.net blogging to late 2009.


Mar 2012

Dec 2009


March 08, 11:15 PM
Ron Ross and Gladys Lam have written an important book for the business analyst community.

It aims to get business analysts out of the technology ghetto that many of us get stuck in. Regardless of the type of analyst you are, I think it would be worth your time to get your hands on and read this book.

I wrote a book review which you can read at Modern Analyst.
March 08, 03:29 PM

Scrum and XP expressly call for respect for people in their value statements, and the Agile Manifesto reminds us that individuals and interactions are of primary importance.  How does this affect us on a day to day level?

Yesterday I went to a mandatory EEO briefing session at work.   What struck me was how rooted in a Marxist, adversarial world-view our employment law seems to be.  Upon further listening and reflection, it seems it is less the law and more management's defensive response to risks and issues highlighted in legislation and case law.

While I am not an expert in the field I have a few ideas I'd like to share.

  • By respecting people (even annoying people like me) you are able to have open conversations and address issues that otherwise might be deemed risky, and this deferred, hidden and allowed to escalate until they become larger and more difficult to deal with
  • By putting the manager 'in charge' of dealing with worker issues like discrimination and harassment, the workforce are dis-empowered, leading to a likelihood of issues coming up
  • By focusing on failure modes (ie what could go wrong), HR policy seems to lead to managers operating out of a fear and compliance mindset rather than one focusing on positive outcomes, which for the most part can be achieved by...
  • Building a workplace that encourages mutual respect for each other 
Respect not only helps us have a workplace free from harassment and discrimination, it also enables us to work more effectively as a team.  Rather than some notion of fairness, where everyone must contribute equally, we are more likely to work from a perspective of everyone does their best for the team's interests, and it doesn't matter whether the contribution is equal. (After all, it can't be.)  This then saves us time worrying about unequal contributions, the best desks, who gets to work earliest, etc.

I am curious to see what you guys think.  What affects do you observe from teams that focus on respect for individuals versus ones where respect is less prominent.

(edit: 2 minutes after hitting 'post' I came across this blog post at Customer Bliss. Worth taking a look.)
March 05, 11:07 PM

Angela joined a team as a PM where one of the first comments I received from a developer was “The way we work around here is code any old thing and then let the testers tell us how to improve it.” (Little did she know he was a closet TDD advocate!) Quality was notoriously low. The track record for IT projects at this project was so abysmal some executives had wondered aloud whether they should even be doing any, and whether the IT development function should be outsourced entirely.

On a two year software adventure Angela and her team adopted XP coding practices within a scrum framework. It took 6 months from inception to the first roll-out and several moderate bugs were found, and only a handful of bugs of real significance. They were resolved within a week. From that week on the team were able to successfully roll out 36 more releases with only an occasional major defect making it beyond a sprint review. The handful of defects that did emerge were found in UAT within a few hours of exploratory testing.

Angela’s role in this great quality outcome was in enabling the team to pursue the quality standards they wanted to work with and nudging them onward to ever higher standards every now and again. She did this by making the team accountable for their decisions and for the work output and making sure that the many feedback loops built into XP and scrum were effective.

Leaders emerged from within the team that championed quality. They build test suites and brought in automated UI testing tools. Everyone on the team tested rigorously and everyone took ownership of the product and accountability for what they delivered to clients. Angela assisted by coaching the customer on acceptance standards, and ensuring the team got sufficient feedback when a feature was not sufficiently done.

Over time Angela spent less and less time working with the team and more time coaching and mentoring the enterprise clients to the project. While not formally adopting a method like scrum the user community also adopted the principles of short feedback cycles and increased focus to get things done within their operations space. Everyone experienced improved efficiency as a result of a focus on quality via feedback loops. The efficiency win in this case was in the reduced amount of rework, and increased alignment on mutual goals.
March 02, 11:37 PM

Over the years I have seen some tweets and posts with the phrase positive deviance and generally assumed this to mean the variation from normal on the winners side of the bell curve. Yesterday I started reading Rabovich and DeRosa's (Nov 2011) paper "Patterns of Success in Systems Engineering" which prefaces its findings with an explanation of the idea of positive deviance.

While I was on the right track, it turns out that positive deviance has a lot more to it.  Positive deviance has a Wikipedia article where you can read about the concept and where it came from. I want to talk about how it is relevant to me and my job.  A couple of quick ideas for now.  I'll be reading more soon.

Positive deviance and best practices
I rant against best practices every opportunity I can.  Apart from the popular notion that best practices are a red herring because there are usually many equally good pathways to a result, it also assumes a best.  This leads to the limiting idea that you can't beat the competition, you can only match them.

What if, instead we looked at what the best performers did and tried to emulate the parts that will work in our circumstances.  A combination of positive patterns, customised for our situation might give us some sort of real advantage. And what if there were no "best" and instead we always just looked to "better" as our aspirational state.

Positive deviance and lessons learned
Lessons learned so often focus on what went wrong.  Our response is usually to try to plug the gaps in our performance.  In other contexts we think about improving outcomes by exploiting strengths. Why don't we look to the success patterns and adjust the way we operate to be more like them?

Positive deviance and risk management
Risk management, like our lessons learned example above, tends to focus on avoiding problems.  Risk management is a continuing activity with multiple risks constantly adding and subtracting to the net (negative) risk of the project. What if instead of an almost exclusive focus on managing negative risk, we were able to invest in maximising positive risk as well?


March 01, 05:00 PM
I'm a massive Lord of the Rings fan. Every year, I spend part of my holiday vacation rewatching the 12 hours of the blu-ray extended edition. Yes, I am just that big of a geek.

As much as Gollum has his precious ring, I, too have a precious. Its something that is very dear to me, mostly because of how little of it I have. Most of it each week is taken up with my job (50+), my commute (~10), sleeping (~56) and the rest to my family (basically the weekends). It is time.

The little free time I have usually is spent helping me unwind from all the other things going on in my life. I brew beer, but usually every other month or so. I work on my classic 1965 Ford Mustang (barely drivable since 2003) maybe 3 times per year (which is equal to how many times I take it out for a drive). I blog (you can see what my posting frequency has been like in the last month to see how poorly that has gone). Other than that, and a little web surfing, that's about it.

What you'll notice in there is that there is precious little time in my life for the things that really get me going... ideas. My work provides me the opportunity to do that more than what most people are allowed, but its still not very often. The times I find myself most frustrated with my job is when I realize my outlets for creativity are being stifled in the name of a project deadline or the endless stream of meetings.

My last 3 weeks have been just absolutely insane. No one real big thing has been driving it, but what I thought would be a slowing down, once I got most of my team in place, has really been nothing more than a massive speeding up as I get to do my real job instead of all the additional tasks I've been doing just to keep the wheels from falling off the proverbial car.

Its because of this that the latest entry of Rands in Repose hit so close to home. Let me give you some quotes that really hit home exactly why I feel as I do:
When an engineer becomes a lead or a manager, they create a professional satisfaction gap. They’ve observed this gap long before they became a lead with the question: “What does my boss do all day? I see him running around like something is on fire, but… what does he actually do?” The question gets personal when the now freshly minted manager begins to understand that life as a lead is an endless list of little things that collectively keep you busy, but, in aggregate, don’t feel much like progress. <emphasis mine>
Thing is, it isn't just an engineer who feels this. When I was 'just' a business analyst, putting the last finishing touches on a requirements document prior to sign-off was such an amazing rush. Sitting down for a few hours to really knock the last rough edges off something, coming out with a well-formed, highly-usable set of requirements gave such an amazing sense of accomplishment.

Now, I have an endless parade of meetings, some of which I must be honest and tell you, I don't even know what they are about before I walk into the room. This happened to me twice. Today.
You would not believe how many times your boss has walked into a meeting with absolutely no clue what is supposed to happen during that meeting. Managers have developed aggressive context acquisition skills. They walk into the room and immediately assess whose meeting it is, listen intensely for the first five minutes to figure out why they’re there all, while sporting a well-rehearsed facial expression that conveys to the entire room, “Yes, yes, I certainly know what is going on here”.
The fact that this had happened to me twice on the day I read this article was not lost on me. While its nice to realize that my boss probably suffers from this same affliction, its hard to go from someone who spent his day accomplishing so many things to being the person who helps other people accomplish things all day.

It is Rand's solution that impresses me most... block out time to be creative; to focus on this every single day.
Starting at the beginning of February, I made a change. Each day I blocked off a precious hour to build something.
Every day. One hour. No matter what.
Every day? Yup. Including weekends.
A hour? Yup, 60 full minutes. More if I can afford it.
I cannot tell you what I would give to have an hour a day with zero interruptions to just create. I cannot imagine the number of ideas that have been rolling around in my head for months that would get done. I cannot imagine what amazing development plans I could create for my employees. I cannot imagine what new recommendations for the company would blossom just given that space to soak in fertile soil.

I wish it did not feel like an impossible dream. In the end, the author inspires me, but to what, I cannot say. One of his final thoughts speaks volumes to me, and I hope it does to you as well.
What would you create if you had eight uninterrupted hours - every month?

Posts

April 04, 08:24 PM

October 04, 01:05 AM

We ran a lunchtime session talking about values and how they underpin the way we work. The session closed out with a whiteboard exercise which is described on the last page of this deck. If you use this I’d appreciate your sharing your experiences and feedback via the comments or by email. Thanks!
August 07, 08:28 AM

I gave this talk at PMOZ last week.
June 01, 11:49 PM

This is a short introduction presentation for the PMOZ conference in Sydney later this year.
May 29, 09:44 AM

In May 2011 I presented this discussion of why project scope is driven by requirements, how requirements change is inevitable, and how that makes good project estimates very difficult. I then present one useful technique for managing this challenge.
April 12, 09:37 AM

I gave this to the Melbourne Scrum Users Group. It was an interesting group with a few experience scrum users and many inexperienced people via the ACS, so the talk had to accommodate some Scrum 101 stuff, and went longer than planned with me talking for a bit over an hour. In the end it went well, and I hope I get some feedback from the audience via the meetup site and ACS website.
January 22, 06:54 AM

When Business Analysts take their analysis and recommendations to stakeholders, we often use workshops. There is a trap in the workshop. You can only fit so much communica
August 05, 05:04 AM

Where are we 18 months after the teams adopted scrum. Where do we want to go?
September 23, 02:24 AM

a presentation on how a business analyst can fit themselves into an agile/scrum project. Comments very welcome.
June 13, 08:13 AM

Using Kano Analysis to prioritise Business Requirements Noriaki Kano, recipient of the Deming Prize, developed a model to work out what stakeholder requirements are mandatory, which ones are value for money proposition (i.e. more is better,) and which requirements will delight them. This talk introduces the Kano model in the business/software requirements context, and presents a step by step application of the model so that you can delight your stakeholders.
February 19, 08:07 AM

Some notes on how to assess a project brief or business case proposal. Don’t buy what you hear on face value.
February 12, 08:23 AM

A guide on how to review and give feedback to business requirements documents for software projects.
January 16, 07:54 AM

A summary of the more popular software develpment processes and methods.
October 10, 12:27 AM

A little information on writing good user stories
October 07, 05:31 AM

Wrapping up the intor to project management series with a skim across some conemparary issues.
October 04, 05:03 AM

Some thoughts on the challenges of goal alignment between consultants and clients
September 28, 03:37 AM

A wide ranging discussion on issues surrounding the globalisation of the project workforce
September 24, 08:30 AM

How to monitor your project once it’s underway. Is it going accoridng to plan?

Posts

May 08, 10:12 PM

Melbourne Agile and Scrum User Group

This session will be centred around user experience and how it can integrate into agile developments.

We will have an overview of Agile UX from Peter Grierson from REA and then have a panel discussion relating to your real world examples of Agile UX at work

The panel will use a Fishbowl format to allow everyone to take part in the discussion.

NB - This meetup is not on the last Wednesday of the month, as usual, so as not to clash with Agile Australia.

The venue is on St Kilda Road, so please allow for travel time, so that we can start and finish promptly.

Melbourne - Australia

Wednesday, May 23 at 6:00 PM

Attending: 100

Details: http://www.meetup.com/scrum-12/events/57046592/

May 10, 09:15 PM

Melbourne Agile and Scrum User Group

What does a scrum team look like 24 or more months after the first sprint?

We ask you, experienced scrummers to bring in pictures of your task boards, visible charts, burn down charts, User Stories and share with the rest of us what you do differently now.

Any Volunteers?

Melbourne - Australia

Wednesday, June 27 at 6:00 PM

Attending: 33

Details: http://www.meetup.com/scrum-12/events/60373232/

May 09, 12:47 AM

Melbourne Agile and Scrum User Group

NB - Registrations are being accepted through the LAST Conference website and not on Meetup.

If you use Meetup to RSVP, you will not be registered for the conference.

www.lastconference.com

================================-

LAST Day Melbourne is a one day, low cost, grassroots mini-conference for Lean, Agile, and Systems Thinking practitioners.

The day will be structured to allow participation and interaction via workshops and activities, rather than death by projector.

The emphasis will be on:

  • sharing of practical skills
  • real world experiences of lean and agile adoption
  • the latest in systems thinking practice

We are looking for submissions and participation from practitioners and support from sponsors.

Follow @last_conf on Twitter, or email us.

Conference details will be published at the website: www.Lastconference.com

We would love to see you there.

Hawthorn - Australia

Friday, July 27 at 9:00 AM

Attending: 9

Details: http://www.meetup.com/scrum-12/events/58309792/

April 20, 03:20 AM

Melbourne Agile and Scrum User Group

We invite agile tool vendors to come and demonstrate their products and explain them in the context of agile development.

Melbourne - Australia

Wednesday, August 29 at 6:00 PM

Attending: 20

Details: http://www.meetup.com/scrum-12/events/59970722/

May 20, 10:41 PM

Melbourne Agile and Scrum User Group

TBC. Suggest a topic

Melbourne - Australia

Wednesday, September 26 at 6:00 PM

Attending: 1

Details: http://www.meetup.com/scrum-12/events/cmtvtyqmbjc/

May 17, 06:00 AM

Melbourne Agile and Scrum User Group

Given the popularity of the May "UX and Agile" perhaps we should run a repeat?

Melbourne - Australia

Wednesday, October 31 at 6:00 PM

Attending: 1

Details: http://www.meetup.com/scrum-12/events/65166472/

Posts

May 16, 04:39 AM

Agile Business Analysts, Melbourne

Want to know what's going on in the Agile recruitment space in Melbourne?

This month we bring you a panel of four recruiters who deal with Agile roles Given our agenda at this group there will be a particular focus on BA, PM and QA type gigs.

If you have particular questions feel free to post them below on this page's comments.

If anyone wants to be a part of the panel or the organisation of this event contact Trent.

Melbourne - Australia

Tuesday, June 12 at 6:00 PM

Attending: 30

Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/60095662/

May 10, 09:35 AM

Agile Business Analysts, Melbourne

The IIBA present the Agile extension to the BABOK.

Melbourne - Australia

Tuesday, July 10 at 6:00 PM

Attending: 17

Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/59957622/

April 18, 11:51 PM

Agile Business Analysts, Melbourne

NB - Registrations are being accepted through the LAST Conference website and not on Meetup. If you use Meetup to RSVP, you will not be registered for the conference.

www.lastconference.com

================================-

LAST Day Melbourne is a one day, low cost, grassroots conference for Lean, Agile, and Systems Thinking practitioners.

The day will be structured to allow participation and interaction via workshops and activities, rather than death by projector.

The emphasis will be on:

  • sharing of practical skills
  • real world experiences of lean and agile adoption
  • the latest in systems thinking practice

We are looking for submissions and participation from practitioners and support from sponsors.

Follow @last_conf on Twitter, or email us.

Conference details will be published at the website:www.Lastconference.com

We would love to see you there.

Hawthorn - Australia

Friday, July 27 at 9:00 AM

Attending: 12

Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/61070682/

April 23, 11:16 PM

Agile Business Analysts, Melbourne

What issues to analysts, line and practice managers and project managers face as analysts transition to an agile way of working?

 

If you are a BA manager in particular we'd love to hear from you and maybe get you involved in the facilitation of this session..

Melbourne - Australia

Tuesday, August 14 at 6:00 PM

Attending: 5

Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/61870122/

April 10, 08:41 AM

Agile Business Analysts, Melbourne

All too often the conversation gets stuck in the software development context.  the true value of the business analyst lies in understanding the big picture and helping everyone with context.

Let's take a look at a handful of "business analysis" tools taught in business schools.

In the context of both projects and operations work, these models are useful for helping everyone not only think about the big picture, but about the scope of what we are trying to achieve.

They also help you speak in the same language as executives.

Format: To be decided.

Audience: All analysts can benefit from this, but particularly useful to those that deal with project initiation activities.

Melbourne - Australia

Tuesday, September 11 at 6:00 PM

Attending: 3

Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/59958292/

May 20, 10:41 PM

Agile Business Analysts, Melbourne


Melbourne - Australia

Tuesday, October 9 at 6:00 PM

Attending: 1

Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/cmkvvyqnbmb/

May 20, 10:41 PM

Agile Business Analysts, Melbourne


Melbourne - Australia

Tuesday, November 13 at 6:00 PM

Attending: 1

Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/cmkvvyqpbrb/

Profile

Head of Project Management & Assurance at Swinburne University of Technology
Management Consulting | Melbourne Area, Australia, AU

Summary

Craig’s roles over the past decade have involved leading project management teams, projects and programmes, consulting, training and coaching in a variety of aspects of project delivery.

Apart from the disciplines of project and portfolio management Craig has a deep understanding of Agile and Lean methods. He is also a leader in the international and Melbourne industry community, having led both the agile Scrum and Business Analysts groups over the last year and a half, and presenting at industry conferences in Australia and India.

Craig has particular strengths in the up-front part of project preparation and planning and has a wide range of experience in structured strategic planning, business model design, business casing, estimating, and business requirements through to stakeholder identification, engagement and management.
Specialties: Leadership, Communication, Planning, Analysis, Agile, Scrum, Project Management, Program Management, Requirements Management, Business Improvement, Consulting

Experience

  • Jul 2011 - Present
    Head of Project Management & Assurance / Swinburne University of Technology
    I manage the project delivery capability at Swinburne's IT department. This includes project managers, business analysts, quality analysts and testers. I am also engaged in working with business partners to the IT department to help increase overall project and product delivery capability.
  • Jul 2011 - Present
    Occasional Agile Trainer @ Telstra / Accenture
    Participating in the agile adoption at Australia's largest telco.
  • Jan 2008 - Present
    Director / Evaluator.com.au
    Consulting business that helps you understand how to improve your project and technology performance.
  • Oct 2010 - Present
    Consultant / Business Analysts Pty Ltd
    I worked with organisations to increase their project capability through systematic improvements to process, systems and tools. I also coach with people on BA and PM techniques and methods and also help out on projects at a practical level.
  • May 2008 - Present
    Program Manager / Workcover NSW
    Managing strategic program updating business models, replacing legacy IT systems with both in house and vendor delivered solutions, and implementing Scrum along the way.
  • Mar 2008 - Present
    Lecturer / Melbourne Institute of Technology
    Lecturer in Project Management to Masters degree students.
  • Apr 2008 - Present
    Consultant / St George Bank
    Project recovery and strategy work.
  • Jul 2005 - Present
    Project Consultant / OptimiseIT
    Projects I worked on at ANZ Mortgages included; - Strategic planning - Major IT programs - Enhance corporate web site (sales channels) - Six Sigma projects - Training and coaching staff
  • Jul 2005 - Present
    Project Consultant / ANZ
    Working via OptimiseIT
  • Dec 2006 - Present
    Project Manager / Telstra Business
    Managing new products to launch for Testra's business customers.
  • Sept 2003 - Present
    Director / erina legal
    Erina Legal is a law firm based upon the Central Coast of NSW. The practice areas are Family Law, Property Law (especially conveyancing), Business Law, and Wills and Estates.
  • Dec 1997 - Present
    Various roles / Optus
    Project Manager, Manager of the Business Process Improvement (BPR) Team, Business Analyst, IT Management, Technical support. For me, Optus was several years of working with great people on cool projects.

Education

  • 2005 - 2007
    RMIT University
    Masters in Project Management
  • 1990 - 1994
    University of Newcastle
    Bachelor in Business
  • 1983 - 1988
    Henry Kendall High School

Additional Information

Posts

November 24, 10:05 PM

The Victorian State Ombudsman tabled his report titled “Investigation into ICT Enabled Projects – November 2011” in which he analysed the performance of 10 high-profile publicly financed projects. The findings of the Ombudsman’s report are fascinating and today I would like to focus, in a bullet point and short format, on his findings as relate to the Myki project.

  • A 2004 Business Case by the Transport Ticketing Authority (TTA) forecasted total expenditure of $741.9 million over the life of the project (2004-17).
  • Project costs revised up to $999 when a vendor was appointed to develop the system in 2005.
  • In April 2008, the budget was increased to $1.35 billion (an increase of 35% in just under 3 years).
  • Under the terms of the original contract, the system was to be fully operational by July 2007. Full implementation is yet to be achieved and the project is some four years behind schedule.
  • Until two years into the project (when the project failed to meet its two years delivery deadline) the board of the TTA had a single board member with relevant ICT projects’ experience.
  • In the initial evaluation of the six tenderers, only the successful bidder was unable to evidence a proven solution: all others nominated sites where their solutions were in place.

Corruption or stupidity? Either way the cost will be covered using my tax money.

For more information regarding the general trends associated with Transportation Infrastructure projects read my earlier post on Bent Flyvbjerg’s research on Cost Overruns in Transport Infrastructure Projects.

October 12, 09:26 AM

Hiya

I have been wrong about many things – I am happy to admit that. In SharePoint land, one of my bigger naive assumptions was that in early 2007, I figured I’d have maybe a 6 month head start before the rest of the industry began to learn from its initial SharePoint deployment mistakes and start delivering SharePoint “properly.” I thought that I’d better make hay while the sun shines, so to speak, as the market would tighten up as more players entered it.

Yet here we are, heading to the latter half of 2011 – some five years later. As I continue to go into organisations, whether in a SharePoint remedial capacity, or a training/architect capacity, I am still seeing the legacy of really poor SharePoint outcomes. Furthermore I am seeing other, frankly disturbing trends that leave me both concerned and pessimistic. I now have a label for this concern: “SharePoint Fatigue Syndrome.” SharePoint Fatigue Syndrome is hard to define, yet its effects are there for all to see. I suffer from it at times, and I am certain others do too. As an example, recently on the Perth SharePoint User Group on LinkedIn the following topic for discussion was raised:

Hi folks, as you already know we have a worrying skills shortage in SharePoint Development / Architecture in Perth and things are getting worse. It’s getting to the stage where companies have to suspend or worse still abandon their SharePoint projects due to lack of available talent. As the core of the SharePoint community in Perth your suggestions are vital towards finding real solutions to this growing problem. What can be done?

Now I know that this problem is not just limited to Perth. There are consistently reports online that speak of SharePoint people being in demand. So you would think that in a “hot” sector like SharePoint, where the industry is crying out for talent, that the rate of attrition would not outpace the uptake of new talent. After all – money talks, right? If you are a .NET developer with half a brain, there is serious money to be made in SharePoint development land. On top of that, there is the collective realisation in the marketplace that actually talking to people about how SharePoint could make their lives easier, leads to better outcomes. Hence the emergence of this notion of a “SharePoint Architect” with a more varied skill-set that just tech or dev. This role has further been legitimised by entire conferences now just catering to the business this end of the market (I am thinking the Share conferences here).

So, we have all of this newfound collective wisdom spreading through the community via various channels, in terms of the skills and roles required in SharePoint circa 2011 and beyond. We have the fat pay-packets being commanded as a result of demand for these skills. So, with that in mind, why is the attrition rate growing?

As an example, I know personally, several exceptional SharePoint practitioners who are no longer in SharePoint. I’ve also had various quiet conversations with many SharePoint practitioners, right up to SharePoint MCM’s, who vent their various frustrations on how difficult it is to get truly lasting SharePoint solutions in their clients and organisations. I’ve reflected on the various reasons I have come to the conclusion that SharePoint is just plain tiring. As a result, people are burning themselves out.

7 causes of SharePoint Fatigue Syndrome…

Burnout, in case you are not aware, is actually a lack of emotional attachment to what you are doing.  Quoting about.com:

The term “burnout” is a relatively new term, first coined in 1974 by Herbert Freudenberger, in his book, “Burnout: The High Cost of High Achievement.” He originally defined ‘burnout’ as “the extinction of motivation or incentive, especially where one’s devotion to a cause or relationship fails to produce the desired results.

SharePoint Fatigue Syndrome is SharePoint manifested burnout. The symptoms include feeling physically and emotionally drained, difficulty maintaining optimism and energy levels, feeling that you have less to give as the burden of work seems overwhelming. Sound familiar?

So why does SharePoint work run this risk? I see 7 major reasons.

1: Cost pressure leading to overwork

First up, the lure of the big dollar is a double edged sword. Not long ago I shared a beer with a SharePoint developer who’s work I respect greatly, yet I can’t afford to hire. This is because the percentage of chargeable hours he would need to work just so I can break even, is very high. This puts me (the employer) under pressure and at risk. As a result, I need to ensure that my newly minted SharePoint employee is productive from day 1 and I need him to work a lot of hours. But here is the irony. When I had my beer with this developer, the conversation started with him lamenting to me that he is already pulling ridiculous hours (60 to 80 per week). He was looking for a job with less hours and yet more money. This is simply not sustainable, both for employer and employee. The more you chase one (work hours vs. money), the more you lose the other it seems.

2: Structures that force an inappropriate problem solving paradigm (and wicked problems of course)

Then there is the broader problem where structure influences behaviour. As a basic example: from the developers’ perspective, they have to put up with sales guys who promise the world, and project managers who then make their life hell and force them to cut corners delivering the impossible. Project managers find out that their beloved work breakdown structure gets chopped and changed when their pain-in-the-ass developers whine that they can’t make the schedule. As I have stated many times previously, SharePoint project are likely to have wicked problem aspects to them. The structures that work well to deliver tame problems, such as Exchange, a VOIP system or a network upgrade, are much less effective for SharePoint projects. While organisations persist with approaches that consistently fail to deliver good outcomes, and don’t look at the structural issues, the attrition rate will continue. There is only so much that someone can take putting up with these sorts of stresses.

3: Technical complexity

SharePoint’s technical complexity plays a part too. No-one person understands the product in its entirety. The closest person I know is Spence and ages ago on twitter he remarked that even within Microsoft no-one understood it all. As a result, it is simply too easy to make a costly mistake via an untested assumption. (I thought the user profile service was tough – until I did federated claims authentication and multitenancy that is). The utter myriad of features, design options and their even greater number of caveats, mean that one can make a simple design mistake that causes the entire logical edifice of an information architecture to come crashing down. Many have experienced the feeling of having to tell someone that the project time and cost is about to blow out because nobody realised that, say,  Managed Metadata has a bunch of issues that precludes its use in many circumstances. Accordingly, SharePoint architects learn pretty quickly that it is hard to answer a definite “yes” to many questions, because to do so would require a question worded like a contractual clause, to ensure it is framed with appropriate caveats. Even then, consultants would know that lingering feeling in the back of their mind that they might have missed an assumption. This brings me onto…

4: Pace of change

This is BIG…and becoming more acute. Remember the saying ‘The only certainties in life are death and taxes?’ Outside of that, the future is always unpredictable.

In between SharePoint 2003 and SharePoint 2007, the wave of Web 2.0 and social networking broke, forever changing how we collaborate and work with information online (and some of those effects are still to be felt). Microsoft, like any smart organisation, responds to the sentiment of its client base. Microsoft also, like most mature organisations, tends to hedge its bets in terms of marketplace strategy in which it tries to get in on the act with the cool kids, yet tries not to kill the goose that laid the golden egg. Just look at Windows 8’s new interface, tablets, app stores and the cloud.

But that is one facet. Change happens in many forms and at many scales. For example, at a project level, it may mean a key team member leaves the organisation suddenly (SharePoint fatigue no doubt). At a global and organisational level, events like the odd global financial crisis force organisations to change strategic focus very quickly indeed.

I don’t know about you, but when Windows 8 was announced recently I was not excited (in fact I was not excited by SharePoint 2010 either). I thought to myself “So soon? I am still figuring out the current platform!”

As an example of the effect of pace of change, consider all the Government 2.0 initiatives around the world. Collaboration is in-vogue baby, so information should be free and government agencies should engage with the community. While that’s nice and all, there is the world of compliance, security and records management that takes a very different view. So, we end up with market forces that push against each other in combination with vendors hedging strategy of being all things to all people. It’s little wonder that SharePoint projects become very complex very fast.

By the way, it is worthwhile checking out what Bill Brantley in this post sums up the whole government 2.0 issue when he said:

What exactly is the nature of the Gov 2.0 challenge? This question was inspired by Andrew Krzmarzick’s post (What Gov 2.0 Needs Now: Managers, Money and Models) and Christina Morrison’s post (What is Gov 2.0? A survey of Government IT pros) on the recent GovLoop survey about Gov 2.0. As Andrew and Christina argued, the survey demonstrates many differing perspectives on Gov 2.0 in terms of what it actually means and how to implement Gov 2.0. To me, this suggests that Gov 2.0 is the classic wicked problem

5: SharePoint Entropy

One of my clients (who you will meet in my book when it’s published), once said to me “All good ideas eventually deteriorate into hard work.” This is a nice way to lead into the concept of SharePoint entropy, which in some ways is the inevitable outcome from the first four symptoms. The easiest way to understand entropy is to watch this awesome TV series called the “Wonders of The Universe.” In that show, the concept of entropy was discussed and for me made a lot of intrinsic sense. Without getting into the detail, entropy is the notion that over time things move from an organised to less organised state. Rather than have me waste your time trying to explain it in prose, let’s listen to the show in question. (Don’t skip the video – this is important!)

Now what does this has to do with SharePoint fatigue? Gordon Whyte saw what I am getting at with his post on entropy within organisations, especially in relation to change management.

For example, when we build a car we take raw materials such as metal, leather, plastic and glass and arrange them in a highly organised way to make a car. But if we then leave that car for long enough the metal will rust, the glass will become brittle and break and the leather will dry out and turn to dust. If the car is left for a very long time it will eventually disappear altogether. This thought left me wondering about the nature of organisations. If a progression from order to chaos is the natural order of the universe, then is this same pressure present in organisations and, perhaps more importantly, what is the optimum position for an organisation between the extremes of rigid inflexibility (low entropy) and complete chaos (high entropy)? This question is not as crazy as it might at first appear”

Gordon has nailed the issue in his post. Any SharePoint solution that has a low entropic nature requires more energy and effort to maintain that order and control. Complex SharePoint solutions often have complex governance wrapped around them. Governance that is process and structure centric by definition, has low entropy and accordingly, needs higher effort to maintain over time. In fact, if you do not maintain that effort and energy, then any SharePoint solution will usually disintegrate back into the sort of information management chaos that gave rise to SharePoint in the first place!  Rather like the sandcastle in the video.

By the way, I feel that email and file shares are high entropy solutions – all failed SharePoint projects lead back to these tools because they require less structure to maintain (in the short term).

In short, if SharePoint is implemented with low entropy, more energy is needed to maintain it. Remove the energy and very quickly, things become chaotic again. Governance approaches that are not cognisant of this will never stand the test of time. The question then becomes whether people feel that the end in mind is worth the perceived extra effort that is being asked of them.

6. Social complexity

Social complexity is also somewhat of a result of the first five symptoms. Most organisations have a blame culture. If they didn’t, then people wouldn’t spend so much time trying to position themselves for blame avoidance. Social complexity is the result of turf wars, ideological smackdowns and all of the other sort of things that result in the cliché of “the silos” where people are not talking to each-other in organisations. SharePoint exacerbates social complexity for two main reasons.

Firstly, because it is a collaboration tool, it actually requires some collaboration to put it in! This is often easier said than done. Secondly, because it is a pervasive and disruptive technology, it almost always clashes with an established tool, process or practice where proponents aren’t willing to change. In fact, they may not even recognise that there is a problem to solve – especially when SharePoint has been thrust upon them. (In an old post, I wrote about the notion of memeplexes and the ideological immune mechanisms that they create and why it is so hard to get shared understanding across departmental boundaries in organisations. Memetic smackdowns are the result).

The long and the short of social complexity is that there is only so much stress people can take. We all seem to have a pathological need to seek order and safety, rather then remain in a stressful situation. Once social complexity bites, the merry-go-round of staff attrition really starts to bite…

7. Meaning over motivation…

Now if I haven’t completely depressed you, let me offer you a perverse glimmer of light. For those of us who understand the preceding 6 fatigue symptoms, recognise them for what they are and take steps to mitigating them, there is one other symptom that contributes to SharePoint Fatigue Syndrome. This is the trickiest of all – and I am a somewhat willing victim of it.

I have spent a lot of time learning techniques to help address the symptoms I outlined here and as it turns out, these skills are universally applicable, whether in SharePoint, IT or beyond IT. For years now, I have metaphorically had one foot out of the SharePoint world door and the other foot into the world of construction, health and management sectors. Hell…I have written what I think is the first business book ever by a SharePoint person that is a non SharePoint and non IT. I also have clients with SharePoint deployments who do not know me as a SharePoint person at all, but only as a sensemaker (and for that I am grateful.)

The point is this: While the investment in these skills enables me to counter the effects of SharePoint fatigue syndrome, it is also inexorably pulling me away from SharePoint work. It seems that once you crack this nut a little, your skills are in demand across the entire problem solving spectrum. Right now this is my coping mechanism for SharePoint Fatigue Syndrome – I get to step away from SharePoint for periods and work on something else. Eventually…inevitably…I will also be one of those attrition statistics.

Conclusion:

The problem is that SharePoint Fatigue Syndrome is a negatively reinforcing cycle. As evidenced by the SharePoint attrition rate, money isn’t that great a motivator. If it was, then the void of skilled resources would have been filled by now. Paying more money might give you a short term gain, but in the long term is not going to address my seven causes of SharePoint Fatigue Syndrome.

I will leave this admittedly negative sounding post with the key to breaking this cycle. While you can attend my SharePoint Governance and Information Architecture class or Issue Mapping Class to learn many ways, the video below says it all. I encourage you to watch and reflect on it, because it’s the same key point to understanding how to do effective user engagement.

 

Thanks for reading

 

Paul Culmsee

                      

No Tags

October 13, 02:21 PM

In their new book, Beyond Performance: How Great Organizations Build Ultimate Competitive Advantage, Scott Keller and Colin Price identify nine factors that are critical to organizational health: Direction, Accountability, Motivation, Leadership, Coordination & Control, External Orientation, Culture & Climate, Capabilities, Innovation & Learning

Organizations that thrive over the long run, in good times and bad, pay explicit attention to all these issues. Three of them, though, seem particularly crucial as we think about new challenges confronting us today.

Motivation: As products, services and even knowledge itself get commodified ever more rapidly, we need organizations that are capable of producing a steady stream of highly differentiated products and services. This requires imagination, which is, in turn, the product of passion. In business as in other aspects of life, passion is the difference between "insipid" and "inspired." Innovation doesn't come from dispirited employees.

Amazing contributions don't come from employees who feel like conscripts. Therein lies the problem. By one recent estimate, only 14% of employees around the world are highly engaged in their work. This has to change. We must be as rigorous and inventive about inspiring passion and unleashing contribution as we are about every other aspect of business.

External orientation: In our hair-trigger economy, customer preferences change at light speed. Unexpected new challenges can pop up at any moment, and new opportunities come and go quickly. The environment for business is more dynamic, more complex, and more global than ever. Given that, we need organizations that can draw meaningful insights out of the maelstrom of fragmentary and incoherent data that daily surrounds them. We need companies where every individual is equipped to sense emerging trends, where the implications for action are rapidly recognized, and the necessary resources are quickly brought to bear.

The decision lags typical of large, bureaucratic organizations are becoming untenable. Individuals on the front lines must have the discretionary power to respond instantly to shifting circumstances. Rather than moving information up to those with authority, authority must be pushed down to those with real-time information.

Coordination & Control: With global supply chains, distributed production networks, and virtual teams, the challenges of coordination are more pressing than ever. In most organizations, managers are the rivets that hold everything together. They connect activities, teams, programs, and business units. The implicit assumption: coordination requires a hierarchy of coordinators. Problem is, hierarchy adds costs and reduces responsiveness. What's needed now are ways of integrating complex activities with little or no management overhead.

And then there's control. Managers are often the enforcers. It's their job to ensure that procedures are followed, budgets are met, and slackers are punished. But again, a supervisory superstructure is expensive and profoundly disempowering. We need organizations where control comes less from rules and sanctions, and more from norms and peers. We need to radically reduce the management costs associated with both coordination and control.

Hence The Beyond Bureaucracy Challenge, the second leg of the HBR/McKinsey M-Prize for Management Innovation. Help us build organizations that are fundamentally fit for human beings, characterized by:

Total Passion
: We know a lot about what it takes to drive deep engagement: purpose, self-direction, a sense of community, and opportunities to grow are a few of the most important. What we're looking for are examples where engagement has been taken to new heights, where management assumptions, processes, and behaviors have been radically overhauled in ways that create a sense of adventure, that inspire leaps of imagination, that foment excitement, and take the work out of work. If you don't have a real-world case to share, invent a hack — a bold, new idea for turning contented team members into zealous ones.

Outside-In: How can we turn an entire organization into a sensory organ, ever alert to the changing dynamics of the marketplace? How can we dramatically improve the signal-to-noise ratio in environment scanning? How can we ensure that weak signals don't get filtered out when the implications are politically uncomfortable? How can we eliminate the lags between "sense" and "respond?" How do we mobilize teams and resources faster than ever? And how can we inject the voice of the customer into every decision? More generally, how can we create organizations where a lot fewer people are inward-focused and a lot more are outward-focused and where contributions at the edges are every bit as important as those emanating from the center? Once again, we're looking for game-changing practices and mind-flipping hacks.

Managing without Managers: Managing is largely about controlling and coordinating. Can the work of managing be pushed out to the periphery of our organizations? Can it be automated? Can it be dispensed with entirely? Is it possible for an organization to be highly decentralized and precisely synchronized? Can you get discipline without disciplinarians? Are there ways of combining the freedom and flexibility advantages of markets with the control and coordination advantages of traditional hierarchies? Can we reduce the performance drag of our top-heavy management structures without giving anything up in terms of focus and efficiency? To what extent can "self-management" or "peer-management" substitute for "manager-management?" If you've got some hard evidence, or just a wild idea, share it with the world.

Help us turn healthy organizations into world-class athletes that are able to vault over tomorrow's challenges. Learn more about participating in the challenge at the MIX.

October 13, 08:07 AM

Awards are a very interesting thing, especially the motivation for giving them. I’m particularly uneasy about the UK Agile Awards, which ran for the second time this year with the results being announced a few weeks ago. As far as I can tell pretty much all of this years winners have a relationship with one of the sponsors. Lets go through each of the winners and see:

 

Agile Project or Programme Manager of the Year: Chris Berridge

Works for Emergn, who were a sponsor.

Edit: Correction, Chris works for Maersk, who worked with Emergn, who were a sponsor.

Best Agile Project or Innovation: ”Fixing the Flaws in Government IT” – The IfG Report 

IfG worked with Indigo Blue closely on the report, who were a sponsor.

Agile Consultancy of the Year: Indigo Blue

Who were a sponsor

Best Agile Team: The Guardian

Worked closely with Indigo Blue on their major redesign a year or so back, who were a sponsor.

Most Agile Aware Organisation: Simply Business

Not found a link, but not looked that hard. Anyone?

Edit: As per Paul’s comment below Simply Business are associated with Emergn, who were a sponsor

Most Engaged Management Team: IPC Media

A sponsor

Best Use of Agile in the Public Sector: DWP

Working closely with Emergn, who were a sponsor. I also find this one particularly irritating as they haven’t even delivered anything yet! As one of the principles of the Agile Manifesto states, “Working software is the primary measure of progress.”

Best Use of Agile in the Private Sector: BSkyB

Not found a link, but not looked that hard. Anyone?

Best Agile Coach/Mentor: Dot Tudor

Works for TCC, who were a sponsor.

Most Valuable Agile Player (UK)

Keith Richards, who was a sponsor.

 

I’ve no doubt that some of these organisations were approached after they were nominated, but looking at who the sponsors were for the previous year it’s mostly the same faces. Hmm.

Well… if it’s that easy then I hear by announce the Rob Bowley “Agile as Fuck” Award and the winner for 2011 is…

ME!

 

 

October 07, 04:32 AM

A year ago I bought the book “Visual Meetings” (doodling for team productivity) and a Moleskine notebook (of course) on my way back from Washington to Amsterdam. At the stopover in New York I drew this:

And this:

It changed my work. Really.

Before I just had a stack of Moleskine notebooks (what else) full of seemingly unrelated notes. Words. Lots of words.

I knew there was a pattern. Somewhere.

But connecting the dots got just more difficult. Making more notes made things worse. Not better.

So. I started doodling. Making awful simplistic drawings. And I am sharing these drawings. Not to show off my skills. It is more to show you it’s ok if you can only doodle and not create picture perfect images.

This is what I found.

If you make a lot of drawings, a common visual language emerges. You use several symbols over and over again. The use of identical symbols reveal a hidden link.

After the individual images I crafted a “story”. On the topic I find most difficult. Identity. Ok. I also used text and quotes.

I created many pages to explain to myself the things I had written over the last years.

This helped me immensely in explaining this stuff. To you and to myself. Mainly that last part.

It changed my approach to almost every thing that feels complex and appears difficult.

As always. You don’t have to try this. Really.

But before you decide, I hope you have a look at this short (5mins) TED talk by Sunni Brown, author of “Gamestorming”. Doodlers, unite!

Bas de Baar helps people find ways to enjoy the diversity of human interaction in their projects and organizations so that they can get out of their own way and achieve their goals. - Connecting The Dots With Doodling. Making Complex Things Less Complex. is a post from: Project Shrink.

September 27, 07:46 PM

Here is a video of my presentation on challenging requirements, filmed at AgileEE last week, filmed by someone from the audience.

September 23, 04:40 AM

Here is a video of a recent session on effect mapping at the Agile testing UK user group. I introduce effect maps, then Jenny Martin and Kate Warner from Loyalty Management talk about how they applied it in their company, then David Evans presents some ideas on how to improve testing by extending the maps.

September 23, 10:30 AM

For years critics have raised alarms about higher education: rapidly rising tuition costs without corresponding increases in value, a trillion dollars of student debt, compromised access, country club tenure for academics, decreasing relevance of tuition to the real world, among other issues.

The Innovative University

Now Clayton Christensen, the father of the theory of disruptive innovation, and his colleague, Henry J. Eyring, in The Innovative University: Changing the DNA of Higher Education from the Inside Out (Jossey-Bass Higher and Adult Education Series) (Jossey-Bass, 2011) tell the stories of two very different universities—Harvard and BYU-Idaho—and how they are addressing innovation in higher education.

The two universities have an interesting link in that in 2005 the highly successful Dean of Harvard Business School, Kim Clark, surprised everyone by leaving his posaition at Harvard to become the president of BYU-Idaho. BYU-Idaho? Most of his colleagues had never heard of it. The book tells how Clark went about reforming a traditional university, showing his successes as well as the roadblocks he ran into.

After a lengthy examination of the histories of these two very different universities, they discuss how these universities are exploring innovative, less costly ways of performing their uniquely valuable functions and thereby save themselves from decline.

Online education

In particular, the book advocates that colleges and universities embrace online education. It argues that online technology makes a college or university vastly more attractive to a wide subset of students. It gives many people a second chance at learning – i.e. those who cannot afford a traditional college education, those who do not have the flexibility to take part in a full plate of coursework, and late bloomers or dropouts who have fallen behind and now have the chance to catch up. But online learning doesn’t just offer cheaper education for the masses. It improves the student learning experience across the spectrum by allowing students to learn at their own pace and on their own timetable.

Q&A with the authors

I talked recently with the authors about their book.

  1. The book discusses at length the history and evolution of two important but very different universities, Harvard and BYU-Idaho. What do you see as the respective strengths and weakness of these two universities today?

Harvard of course excels in its reputation, faculty, wealth, and alumni network.  Its few significant weaknesses include organizational complexity and high operating cost.  The high cost derives from traits of the traditional research university, such as faculty who spend a relatively small percentage of their time in the classroom and a campus that sits largely idle during the summer.  Also, Harvard has invested heavily in a system of residential housing and high-quality tutoring.  This means that even students who pay the tuition sticker price aren’t covering the full cost of their education.  Thus, growing the size of its “customer” base, which is how businesses achieve scale economies and greater profitability, is financially problematic for Harvard and for other universities with similar operating models.  The number of students they can serve is limited, not because they don’t have enough qualified applicants, but because they can’t afford to subsidize additional students.

BYU-Idaho’s strengths include a low-cost operating model, which derives from (1) faculty focus on undergraduate instruction, (2) year-round operation, and (3) use of online learning technology.  A “Learning Model” common to all courses promotes consistent learning quality, even in online offerings.  BYU-Idaho’s ongoing challenge is to ensure learning quality by rigorously defining and measuring learning outcomes and continuously improving the curriculum.

2.       What is the purpose of a university as depicted in this book? Is it: A. A university is an institution that provides a degree, which is a credential or screening device for the economy and for society? Or B.  A university is an institution in which people acquire the knowledge they need for a particular job? Or C.  A university is an institution in which people acquire the knowledge they need to be a citizen? Or D.  A university is an experience where you acquire a capacity to be a lifelong learner (because most of the knowledge you acquire will be obsolete within a few years and the jobs of tomorrow will not be the jobs of today)? Or E. Something else?

Ideally, a university or college education serves all four of these purposes.  The degree is the easiest to provide, and the types of knowledge listed above are sequentially more difficult to impart.  That becomes increasingly true as the world grows more complex.

3.  Some have argued that goal #2. D. (a capacity for lifelong learning) should be the most important purpose, given the highly dynamic state  of today’s economy. Do you think the book gives enough emphasis to that? How good a job are these two universities doing at that?

The book doesn’t directly address the importance of lifelong learning.  However, it describes learning approaches, such as BYU-Idaho’s Learning Model and Eric Mazur’s use of peer-to-peer instruction at Harvard, that prepare student for lifelong learning.  One of the best ways to learn to learn is to be an active learner and a teacher of one’s fellow students in college.

This instructional philosophy isn’t yet widespread, but its effectiveness has been proven, and it doesn’t require additional financial investment, only a change in the attitudes of faculty members and students.  Broader adoption seems likely, with time.

4.   The book says that in performing its purpose, a university has three “jobs to do”:  discovery, memory and mentoring (p.335). Could you explain this framework?

Traditional universities do three valuable things that other institutions don’t.  All three require talented faculty members with scholarly training.  These things are (1) discovering and disseminating new knowledge, (2) preserving the discoveries of the past, and (3) personally mentoring students in ways that allow them to participate in (1) and (2).  Doing these things well takes special training.  It is inherently expensive, because the processes involved are hard to automate or even systematize very much.  Still the value is great, and society needs universities to do these “jobs.”  The trick is to get the jobs done at a price that students and society can afford.

5.  The book gives both universities generally high marks for discovery and memory of knowledge.  How does this fit with the recent realization that several decades of foreign outsourcing by the private sector have resulted in the loss of knowledge related to huge sectors of the economy, particularly those that crucial for the economy’s future, with no obvious way to get that knowledge back to this country? What role do you see for universities in preventing further loss of knowledge that is crucial for the country’s future?

Economic and social globalization makes the traditional university more valuable than ever.  Unlike most for-profit organizations and even governmental institutions, the university is designed to be global in its pursuit and preservation of knowledge.  Thus, a nation that invests in effective research universities can worry less about the specialization that inevitability occurs as it focuses on the industries and value-adding activities in which it is most competitive.  This won’t happen without thoughtful direction and coordination, but nations with outstanding university systems will continue to enjoy a competitive advantage.  These nations can specialize their activities without losing touch with the full range of knowledge needed to be world leaders.

6. Some have argued that the ability to ask the right questions is today as important as and possibly even more important than a capacity to give the right answers. How well do these two universities do in responding to that challenge?

As mentioned in response to question 3, Harvard and BYU-Idaho involve their students in teaching one another.  They also have general education courses, created in the last five years, that cut across academic disciplines and engage students in applying principles and theories to real-world problems.  These instructional approaches challenge students to frame inquiries, rather than merely respond to questions posed by their professors.  More can be done, but Presidents Derek Bok and Kim Clark, who championed the new GE programs and learning models at their respective institutions, helped their schools go a long way toward graduating students who can ask good questions.

7. The book praises BYU-Idaho for holding costs more or less constant for an in-person degree, i.e. preventing further cost increases (p.300) and cutting costs of an online degree by 75% (p.317). The book gives less information as to what Harvard has done to control costs. Do you think these efforts at cost control are adequate, given that student debt in the USA is now around $1 trillion and growing rapidly?

We all need to be looking constantly for ways to do more with less.  Fortunately, new learning technologies make that possible.  But Harvard and other elite institutions are in a paradoxical position.  Their students and alumni are satisfied with their current offerings; in fact, they have a huge surplus of qualified applicants.  They are exploring and investing in new learning technologies, and they have the capacity to use that technology to serve more students at lower cost, if they choose.  The question is when and how to change in ways that won’t detract from the quality of what they already do.

We’re likely to significant change in the next decade, the net effect of which will be more students served at a lower average cost.  However, the nature of the evolution will differ among institutions.  The elite schools will hybridize their courses not primarily to reduce cost or grow enrollments, but to better serve the rising generation of “digital natives” and to make the most of learning-enhancing computer-adaptive technology.  By contrast, schools without the benefit of high prestige and large endowments will hybridize and offer fully online courses mainly so that they can keep tuition affordable, admit more students, and use the incremental revenues to plug the hole left by rising operating costs and declining state support.  In all cases, students will benefit.

8.  The book says that world needs more university education, not less (p.344). Could you explain what you mean here? Given the financial issues in question #6, how realistic is that?

It’s clear that some form of higher education is becoming more important to making a comfortable living.  That doesn’t necessarily mean a four-year college degree, but I’m certainly challenging my children to make that their first target.  As noted above, new technologies make it possible to provide a good college education at an affordable price.  BYU-Idaho, for example, has online degree programs for $65 per credit, or less than $10,000 in total.  Many students will be willing and able to pay more for a mixture of online and on-campus instruction.  Traditional institutions will offer programs at various points along this spectrum, as for-profit institutions are already doing.  We’re going to see more higher education options, more providers, and more students.

9.       The book seems to suggest that tenure for life is justified for qualified academics (p.377). However philosophically sound and desirable such an approach may be, how realistic do you think this is in the current context where practically no one else in the economy has any guarantee of lifetime employment?

It’s important to clarify what we mean by “tenure.”  First, its performance based: you don’t get it for life unless you perform well for life, based on regular review.  Partnership in a law firm, an investment bank, or a consulting firm may be a helpful analogy.  Second, the activities being performed by the tenured professor must be consistent with the mission of the institution, which for most institutions is likely to be narrower than the mission of a large research university.  Most professors will need to spend the majority of their time teaching.  A school that generates the bulk of its revenues via tuition will be able to afford some time for faculty research.  However, that research will need to have relevance to the student learning experience, and it won’t be the driving factor in tenure decisions; teaching quality will be.  Tenure based primarily on publications isn’t a sustainable model for most institutions.

10. What other questions should I have asked you?

It’s worth noting that we’re predicting a different kind of disruption in higher education than the type seen in computer manufacturing, book publishing, or music and movie distribution.  Traditional university and college campuses won’t go the way of the record shop or the video rental store.  Particularly for young students, a college education is a social experience requiring some amount of face-to-face interaction.  The expensive investments that traditional institutions have made in brick-and-mortar facilities and full-time faculty members will always have unique value.  As these institutions adopt online learning technologies, they will be able to offer the best of both worlds to students who can afford to relocate from home and pay a premium over the cost of a fully online education.  Institutions that cling too long to the old model are unlikely to survive.  But those that innovate quickly have a bright future.

___________________

Steve Denning’s most recent book is: The Leader’s Guide to Radical Management (Jossey-Bass, 2010).

Follow Steve Denning on Twitter @stevedenning

And join the Jossey-Bass webinar series aimed at “Killing Dilbert-style management once and for all”: Sep 22-Oct 20, 2011. The second session begins next Wednesday September 28 at noon ET. To register, go here and use discount code JBMSD.

 

September 24, 05:42 AM

Rob Prinzo and Robert Kelly - the guys behind #pmchat

#pmchat is an awesome weekly tweetup of project management enthusiasts.  It starts every Friday at 4.30pm (GMT) with the pre-game radio show hosted by Rob Prinzo (@robprinzo) and Robert Kelly (@rkelly976).  After the 15 minute webcast, the interactive hour long tweetup kicks off.  Topics covered so far include managing scope, building strong project teams, and gathering requirements.

#pmchat enjoys active participation from a tight community of friendly and experienced professionals including @HELENSStudio, @dwrichy, @klkaz, @Project_Mom,@michael_greer, @irivera, @unlikebefore, @RailComm_Paola, @sewah_kram, @ColleenGarton,  and @BridgePM

I hope you can join us next week

September 13, 01:25 AM

As an industry based lobby group we were faced with Legislation to reduce government funding by $1.9B. We needed to respond quickly and adopted an Agile approach to our digital campaign strategy in order to have a skinny version of the website up and running as soon as possible. We used a mix of Scrum and Kanban methods to prioritize widgets we required on the website and ensure our campaign remained responsive to stakeholders and built iterative changes to the site in order to respond to stakeholders and the political debate.

This is my Agile Lightning talk outlining how a mix of Agile approaches, namely Kanban and Scrum were used as a management tool to coordinate the development of a new website for the campaign. I demonstrated how the adoption of Scrum allowed the team to iteratively build features based on weekly sprint cycles and ensured weekly collaboration and communication between product owner, designers and developers of the website.

 
The introduction of a Kanban board to the Scrum process helped to manage the backlog of work packages and help focus the team on the ranked priorities for the current sprint. This provided a process to manage Workflow and allowed the team to remain flexible and responsive to the changing environment and stakeholder needs when changes were required mid sprint.

Sprint Planning

Sprint Planning was done utilising the Elements of User Experience Framework (Strategy, Scope, Structure, Skeleton and Surface) in order to plan what needed to be produced , what activities were required and requirements we needed to consider.

Kanban Board

  • Needed to prioritize features to ensure campaign remained responsive to stakeholder needs
  • Visual tool to manage the backlog, focus  team on the ranked priorities
  • Process to manage workflow and remain flexible
  • Used it to manage 3 projects within the same program “Scrum of Scrums” Board

What we Learned

Multidisciplinary approach and blend of Agile and UX tools:
◦Remain flexible and responsive
◦Prioritise features and manage the backlog of work
◦Aided focus and coordination
Kanban Board was an effective visual communication tool  (team & org)
Scrum effective way to continuously integrate features and keep the team on track
Value of Scrum Master
 

My Favourite Board – Fin!


September 09, 01:11 AM

Today, the most popular way people prefer to make contact with organizations is online as customers embrace new digital channels. We needed to modernize our digital presence to take the conversation to the channels where those conversations are taking place. Utilising an Agile approach allowed us to increase site usability and responsiveness to consumer needs and adapt and modernise our systems.

What We Did

  • Used Agile and User-Centered Design (UCD) tools to elicit requirements, prioritize and groom backlog
  • Allowed team to collaboration and get buy-in from stakeholders
  • UCD tools developed iteratively to help determine value to stakeholders
  • Agile process allowed alignment of wants and needs to prioritize & provide most value

Approach

Our Scrum Process

  • 2 weekly sprint cycles
  • Continuous integration to build upon skinny solution to respond to evolving needs
  • Collaboration between product owner, scrum master and team
  • Needs changing so estimation of what could be done and definition of done important
  • Prioritisation helped us weight “$$$ Cost” vs “Opportunity Cost” 

I recently presented an overview of the project to my organisation and demonstrated how personas were developed and workshopped with key groups to determine the needs and wants of consumers. The personas were also used to develop user stories which formed the basis of the requirements and feature sets of the site. Card sorting was used to understand how consumers classified the information and what features were of value. A prototype was developed which was a “skinny” version of the site and was used to communicate functionality and desired look and feel of the site to the team and to validate the site with consumers.

Learning Outcome

  • User-centered tools and techniques are effective way to improve collaboration and encourage communication with stakeholders and within the development and design team
  •  Using a multidisciplinary approach (Agile and User Centered Design) enables you to ensure that the website is useable, adaptive and meets the digital needs of the modern 21st century consumer

September 08, 06:13 AM

Why is your project taking place right now? And not last year, or next year? Are there also any other projects taking place now? Why? What is the challenge? This can be either a threat or opportunity that is the cause / reason for the project. What is the legacy the organization wants to leave behind?

These questions matter. A lot.

Being busy in a project can be overwhelming. Before you know it you are only focused on this Big Adventure. Of course, your project is worth your time and attention. And of course, it is an incredible story, this temporary awesomeness that you and your mates are doing right now.

But it is just exactly that. A temporary story. When you’re done, you’re done.

Your project is part of a larger context. Longer journeys. Larger stories. And these stories shape your project more than you know. It’s like Star Wars. You can watch just episode IV. And enjoy it. But it starts really making sense when you watch the entire series.

Your project is an episode in two stories.

The story of you. The individuals that are involved in the project. An individual has an ambition and a reputation. And he has a role in your Big Adventure.

And the story of the organization.

You can address the Story of You with the Map Of You.

The same principles can be applied to the Organizational Journey.

By exploring the relationship of the project and The Organizational Journey, you and your team create awareness around why you doing things. Awareness beyond the normal “build this” specification. A sense of why you are doing what you are doing. This will help the team to make decisions that fulfill the organizations desires and be more in tune with its context.

Draw an empty map which basically looks like a bow tie. Put “NOW” in the center and “PAST” and “FUTURE” on both sides. Ask the participants to write keywords that answer questions as formulated in the first paragraph of this post.

This exercise is related to The Story Of Your Quest – exercise.

Other Maps.

The Organizational Journey is part of a change/project management strategy focused on culture and using an “adventure travel” metaphor. For more maps and exercise, visit my list of Shrinkonian exercises.

Bas de Baar helps people find ways to enjoy the diversity of human interaction in their projects and organizations so that they can get out of their own way and achieve their goals. - The Organizational Journey. Mapping The Project Context. is a post from: Project Shrink.

September 07, 12:48 AM

David G. Wilson brings a quote from Consultant-News.com, suggesting that “more and more people seem to be coming to a realisation that it’s not so much that their problems are complex, but that their problem is complexity“.

I have had a number of goes at the issue of complexity in previous posts and I have to admit that over time my view of what complexity is and why it exists, has changed somewhat.

Let’s see if I can explain it in writing:

From a critical analysis perspective the interesting thing about ‘complexity’ is that in essence, in reality, it does not really exist. It is rather a virtual perception, subjectively created by some observers but not by others. I often hear people commenting how ‘in the past the world used to be simpler’. If you contrast the changing reality in the world over the past 500 years or so it is not difficult to see that what some call ‘increased complexity’ is really increased level of interaction, increased lines of communication, many more interfaces etc. Take for example the modern TV remote control. Today’s TV remote control can still perform the simple task of switching the TV on and off. It can also change channels and control the volume. It can also perform some tasks that were not available in the past. For insance you can now freeze the screen, view what’s on in other channels, insert sub-titles, etc.

So it is not that the world has become more complex, it is us who have changed as we now want to manage far many more interactions than our evolutionary capability is allowing us to do comfortably. And this is where Darwin’s theory kicks in. Those of us who feel more comfortable in managing the increased load will do better than those for whom this increased load is a point of increased pressure, tension and distress.

With the above in mind it is clear that reducing complexity will not be possible unless we change our nature and adopt a less competitive nature. Naturally, this is unlikely to happen and so we can expect complexity to further increase.

Think about it!

 

September 05, 06:04 PM

…is here.


September 02, 03:11 PM

If you asked me to point a single thing, which I hate most in senior management role, I wouldn’t have any problems with the answer. It would be firing people. On my personal hate scale there’s firing, then huge, huge void and only then other unpleasant things and tasks to do.

Each time I fire someone I feel like a complete jerk. It doesn’t matter that the decision is well-grounded. It doesn’t even matter when I’m proven, after some time, it was the right choice. It isn’t any easier.

And the next time you do it doesn’t become any easier either. I mean if executing such decisions is easy for you and you feel comfortable firing people there must be something seriously wrong with you.

Yet I still think firing people is extremely important part of pretty much any management job. If you’re a senior manager you likely have power and authority to make such decisions. If you’re a team manager dealing just with your team of six or something and you don’t have that much of power, you still can convince your superior to make a tough move. Sometimes the latter is even worse as you have to do all the talking as it is you, who started the whole thing.

OK, why is it so important then? Because this is one of methods of building great teams. As harsh as it sounds: sometimes you don’t have enough resources (meaning: time, patience, money) to make a person act on acceptable level and the best thing you can do is to split your ways.

Don’t get me wrong, my advice still is: do everything you reasonably can to fix an underperformer. I know way too many people who started shining when given a second chance to say otherwise. But then remember that it’s a manager who is responsible for building the high-quality team, so if you just accept the underperformer in the team you basically harm the team on many different levels.

What more, sometimes we’re out of luck and we don’t have all the time and money of the world to try virtually every possible thing one could think of. Sometimes our fixing options would be limited. Sometimes constant resistance of the underperformer will make us lose faith faster. Shit happens. We don’t live in ideal world. And then it’s time…

Well, for many managers I know then it’s time just to accept the fact someone is underperforming. And you know what? I understand them. I understand them because firing people is so damn hard and so freaking unpleasant that I can think of thousands of reasons why I shouldn’t do that. At all. So yes, I can perfectly understand them.

But I don’t agree with them. We are paid to do our jobs even when the jobs suck on occasions. When we make our developers write boring documentation which just has to be done it works similarly. The only difference is in level of responsibility. But we still expect our developers would deal with crappy tasks, don’t we?

Having balls to fire people isn’t something which makes a manager. In fact, with a bit of luck we won’t need to fire anyone for years and will be able play the role of guru manager neatly. However, when time comes you better be ready to deal with the worst management task ever. Otherwise your whole team will be constantly taking big hits on morale and you no longer will be considered a rock star manager.

If you’ve just lived through such situation for the first time I have two messages for you. First, it’s one of the most valuable experiences as a manager you can possibly have so good for you. Second, yes, I know how crappy you feel now and it’s not going to become easier next time you do this, sorry.

September 02, 03:04 AM

The discussion of how do you know what done looks like? in the agile software development world has many answers. Ranging from we'll let the customer tell us, to we have this collection of User Stories and Use Cases that tell use what done looks like.

Jens Coldweys (turn on translation) blog speaks to the use of Use Cases and Scenarios in the development of software. These Use Cases and Scenarios need a Reason for existing. This reason is usually missing or is linked to the wrong source.

  • The reason we need this is the customer says we do
  • The reason we need this is that any system like this has this requirement

The missing piece is not only why but the connections between the why and the actual mission outcome. By that a business mission, a government mission, a military mission, any mission.

So before the next step, let's put some definition out there:

  • Mission - why we exist, why we want this system.
  • Values - the guiding principles we'll use in fulfilling the mission
  • Vision - the picture of the future
  • Strategy - the differentiating activities that will be used to fulfill the mission

So where do these Use Cases and Scenarios come from? Good question. No answer to that question? Then these Use Cases and Scenarios have no real reason for being other than someone or some group says they want it. But that usually leads to trouble when those needs and wants themselves don't have an architecture.

  • How do they relate to each other?
  • What are the dependencies between them?
  • Which are more important than others? This is not a ranking system, but which are more important in terms of fulfilling the mission?

The answers to these questions come from the Capabilities Based Plan for the project. This Plan states what capabilities are needed for the mission to be successful, for the system to provide the needed outcomes for the customer, for any result to fulfill its mission.

Don't know what capabilties are needed, the units of measure for those capabilities? Then any set of Use Cases or Scenarios that the user and developers come will likley be OK. This is the same problem with the requirements elicitation process. Requirements need a reason for being. A Raison d'être. Why do we have this requirement, why do we have the Scenario.

Here's how to develop those capabilities statements. Without answering these questions, those wonderful scenarios, Use Cased, User Stories have no real reason for being in the context of a "system."




August 31, 10:00 AM

In 1935, Bill Wilson – an alcoholic whose doctor had given him 6 months to live if he didn’t quit drinking – had a vision. His vision was that while experts were ineffective in curing alcoholism, the addicts themselves were the keys to helping one another overcome the disease. And with that, Alcoholics Anonymous was born. Today, they help over 2 million members and have been the model for numerous Anonymous addiction recovery groups.

In the 1980’s, Richard Stallman’s fierce beliefs in freedom and in the importance of free software (free as in free speech) towards securing the future of a free society led him to create the Free Software Foundation. FSF became the impetus behind the open source movement. Today, developers around the world freely volunteer their time to develop the open source software that tens of millions of us use every day.

In 2000, Jimmy Wales decided to launch a free online encyclopedia for children whose parents couldn’t afford their own. After a tedious process that produced a mere 24 articles, the encyclopedia’s editor – Larry Sanger – introduced wiki technology. That decision led to the 100% user generated encyclopedia that ultimately cost Larry his job. Today, Wikipedia is the world’s largest reference site with over 3.7 million articles. It attracts over 400 million unique visitors every month.

The Community

What is amazing in all of these instances is how people stood up and contributed. Contributed even though there was no clear reward for them to do so. AA members took the 12 Steps and created new chapters around the world, running those chapters with no involvement from Bill W. Developers regularly volunteer their time to create hundreds of thousands of open source projects. Wikipedia’s users not only write the articles, but they serve as custodians to the site. Ask Jimmy Wales who runs Wikipedia’s servers and he’ll tell you he has no idea. The users decide for themselves.

Not only do people voluntarily contribute, but they contribute high quality. A research study found Wikipedia on par with Encyclopedia Britannica for accuracy. And much open source software is considered the best of it’s kind.

The Catalysts

Bill Wilson, Richard Stallman, and Jimmy Wales are all catalysts. Catalysts are visionaries that develop amazing ideas. But instead of holding onto those ideas for themselves, they share their ideas with others. And they inspire others to take action on them. And then, the Catalyst steps out of the way and lets the community carry the idea to incredible results.

Catalysts share their ideas, but they don’t take ownership. If they had, every new AA chapter would have had to go through Bill W. and it would likely have never have reached as many it did. When Jimmy Wale’s initial free encyclopedia was “owned” by him and his editorial team, it managed 24 (as opposed to Wikipedia’s 3.7 million un-owned) articles. And Richard Stallman is quite vocal about his dissatisfaction on open source’s split from his initial vision. But he doesn’t take them down, and so the open source movement continues to grow.

Unstoppable

By not taking ownership, catalysts allow each and every member of the community to take hold of that ownership. The power is distributed to all of the people and these communities become unstoppable as Ori Brafman and Rod Beckstrom describe in The Starfish and the Spider: The Unstoppable Power of Leaderless Organizations.

The catalyst’s presence almost always remains felt, but catalysts understand it’s all about letting go and trusting the community, because that is where the true beauty lies.

“When you give people freedom, you get chaos, but you also get incredible creativity.”

Trust is a beautiful thing.

August 24, 07:20 PM
Eventer doesn't have an embed feature yet... so check out my Ignite Melbourne talk about estimating anything, like pieces of string, via the link below:

http://ignitemelbourne.eventer.com/talks/1001
abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz