I have been at Wikipedia again. This time at the User Story page.  I didn't like the contents as usual, and this time I drafted a variation on the Wikipedia page and published it in the Business Analysts Handbook. A copy is recreated below for your interest.  It also serves well as a first post in the Agile Thursdays series.


Introduction

A User Story is a marker indicating a request for work to be done.

User Stories are often conflated with software or business requirementsbecasue on first impressions they look like requirements. They are actually independent things.

User Stories were first introduced to the world by the XP community in the late 1990s, although the concept of stories and narratives being effective tools for communicating requirements daes back at least into the early 1980s.

Important things to consider about User Stories 

• They are a token for doing a piece of work and are not a software requirement in the traditional sense 
• They are a 'trigger for a conversation ' and build upon the Agile Manifesto principle that face to face conversations are the most effective form of communicating ideas 
• A User Story is likely to evolve over time as people's knowledge on the topics area matures 
• Generally, when a software team starts work on a User Story a clear 'definition of done ' should be available 
• User Stories are ideally written on index cards or similar because of the value of visualizing the workflow , keeping them simple and osmotic communication . 

Card Conversation, Confirmation
The three essential elements of a User Story are the card, conversation and confirmation.

These are described below under the following headings.

• Card = Physical v Electronic 
• Conversation = As a Product Owner I want a template 
• Confirmation = Start with the end in mind 

Physical v Electronic
User Stories are typically written on index cards or post it notes because of the value of osmotic communications, the lightweight nature of the tool and because face to face communication is optimal for project team communications.

Many teams also capture User Stories in electronic media such as requirements management or test tools.

There are many purpose build product backlog management tools on the market.


As a product owner I want a template so that it's easy
Since the mid 2000's a 'common form' of User Story has become dominant. It is presented in the following form;

• As a [user type] 
• I want [an interaction+outcome] 
• So that [I get some form of value] 

The benefits of this templated form are real and tangible. An important part of both requirements management and workflow management is effective partitioning or dividing of the model elements into smaller parts. Diving the stories by the user type is a useful technique. Occasionally a feature or service will be identical for multiple users but more often than not there are differences, subtle or obvious, that the division helps surface.

The "I want" element generally describes some tangible interaction or feature. Because of this element a User Story is often conflated with a Use Case, a scenario or a feature. And it may well describe any of these or other thing.

Again partitioning is relevant and important here. But the main driver in this space is to partition the work into a small, independent pieces of work. (See the INVEST mnemonic.)

Software developers usually have a lot to offer in relation to requirements and how they should best be fulfilled. Often they have been constrained by a lack of awareness of the motivation for the requirement. It's also a common client failing to jump to solutions to early. Asking for the motivation in terms of business value helps everyone focus on what's most important in the story. SO explain why in the "So that" clause.

But the template has it's detractors.
By proving a tamplate in the first place you provide a platform for people to communicate in written form with the idea that the communication is sufficient and complete.

Unlike requirements a User Story is not a complete brief. It is aimed at being a trigger for a conversation and is purposefully incomplete so that the conversations can be had to further elaborate understanding collaboratively.

Start with the end in mind
A clear definition of done is important for User Stories as they re work requests. By being clear about 'done' teams are better able to determine when they have not yet met the minimum quality and capability thresholds, and when they have gone too far.

Typically the definition of done is created via a test case or acceptance criteria prior to commencing work on the user story. Early User Story advoctes simply used the trigger "This will be done when..." to stimulate the discussion on 'done. More recently the idea has been elaborated. From the same vector as the "As A, I want, So that" template comes Behaviour Driven Development (BDD.)

BDD is more than just a form for acceptance criteria. It is also a framework for managing stories and requirements more broadly. But it has also been adopted as teh dominant form for acceptance criteria on User Stories with the template;

• Given 
• When 
• Then 

Where given describes a starting state, when describes a trigger or catalyst and then describes the new state of being. This template form suffers the same strengths and weaknesses as the "As a I want" template.
Further reading

• Mike Cohn's User Stories Explained 
• Wikipedia on User Stories 
• c2.com on User Stories 
• ExtremeProgramming.org on User Stories 
• Scott Ambler on User Stories 
• User Story Template 

Related topics

• INVEST - A quality checklist for User Stories 
• Kanban - another concept for work tokens 
• Story Maps - a way of managing large numbers of stories 
• Behaviour Driven Development - Test thinking applied to stories
• Stories as Inventory - understanding the cost of too many stories (or requirements)

I thought I might try something different with my blogging: A structured approach.

In the early days of this blog I was exploring and discovering techniques and models from the engineering paradigm of project management and requirements.  I learned a great deal of useful stuff, some of which is re-emerging now as part of the Kanban movement.  Given there is so much interest out there in the agile thing I thought I might try a regularly and specifically themed agile blog.

I'll be drawing the post topics from the local Agile meetup groups.  Their goal will not be to give definitive answers on topics, but to raise awareness and to provide a platform for further investigations.  I hope they are useful.

If you want to see a summary of all the topics covered to date try searching the blog for "Agile Thursdays."  

Check lists beat templates hand down.  Checklists say "Have you done enough?"  They help you think through the issues.

And they can become mindless activities as well.  Checking the box unthinkingly, or adding new items to the checklist without ever taking the time to trim some unnecessary items.

But I reckon they are still better than templates. They are definitely more lightweight.

I just created a checklist to help someone with little project experience think through their project needs.  Take a look. I'd appreciate some feedback.

• End to end analysis framework

It's not perfect.  It's not even complete, I'd say.  But how would it stand up as a newbie guide?

You're in the weekly project status update meeting. The agenda has been reviewed. Last week's minutes are quickly discussed. The PM asks for any new business and finally its time to do that last task we all dread...
Review the project schedule.
The PM opens up MS Project, filters by task end date and asks everyone in the room for a status of the tasks that will end during the next week. Its a painful process, takes at least half of the meeting and most everyone is checking email while their colleagues provide updates.
After all the updates are added to the schedule, the PM asks Project to calculate a new end date, only to find that the project just slipped two weeks.
Oops.
Now the PM goes into panic mode. How did this happen? We were ahead of schedule last week and now we're going to be late! Where is the slack time? Who is on the critical path? Can we crash this thing back to baseline?
The sky is falling!!!!
Or is it?
This situation has always bothered me in ways that I never really could put my finger on, but this week I think I finally understood why this bothers me so much. While on my commute, I was listening to the Back to Work podcast, featuring Merlin Mann and Dan Benjamin, and the topic focused on projects and slipping dates. Merlin's main points were not directly related to my epiphany, but it did get me to thinking some about the whole concept.
Here's the deal... I don't believe dates ever slip, no matter what happens in the project plan. Dates are fixed, and not just because some executives says so. The day a project is over, with whatever system or process changes implemented, is the day it was done. It doesn't matter if that day was weeks early or years late, that is the day the project finished. You can't go back and change that date and since it is now live, you can't go forward in time and make it go live again (at least not with that particular phase).
End dates are always fixed, but what isn't fixed is our understanding of that date. Its possible, maybe in probable, that at some point during the project, something will come up which alters our perceptions of the project and how close we believe we are to its end.
The end date did not change, only our ability to accurately see that end date.
Big deal, you say, the effect is the same. That is true, but I believe that understanding end dates in this way changes our perception of projects in general.
If dates 'slip', this is seen as a bad thing; like we're not doing our jobs or that something unforeseen has impacted the schedule in a way that is not easily recoverable.
If my view is correct, then new information has been assimilated and we now have a more accurate picture of reality.
I don't know about you, but I think my viewpoint feels a lot better.

This sat in draft for a while.  It's about bureaucracy, PMOs and change.
Some quick questions to get you involved;

• Do you know the people in your PMO?
• Do they know you?
• Are they committed to seeing your project succeed?
• Really?
• Or are they just about process compliance and weekly status reports?

Some PMOs are really useful, some are less so.

(PMOs are a nebulous thing, so I might run up another post on my views on what makes a good PMO at another time.)

I recall once I had to go into a meeting where I had to justify why I wanted to create addional project documents, and why I wanted to vary from the usual tempaltes.

The reason I wanted to do 'extra' documentation is becasue we want to demonstrate new processes and methods for the organisation, and as a result want to keep them comfortable while w experiment with their people and processes.

We'll follow good agile practices and do fortnightly product reviews, and product burn up charts, and we'll also provide a report showing time and money spent against a target.  We'll work with a backlog full of user stories, and we'll also provide a high level requirements summary for our main release phases, one at a time, focused on the next release.

We definitely want to present a Project Management Plan, and a Quality Plan and Communications & (people) Change Management Plan which aim at explaining our methods and thinking through some of the more complicated parts of the program.

So, if I want to go above and beyond in terms of project documentation why the hassle?

Well, for one thing I also want to omit redundant documentation. In particular some of the requirements documentation.  We already have plenty of detail to hand, so why both rolling it up into multiple summaries and decompositions?  We already have a product vision statement and release roadmap so why elaborate that into additional documents that are at the heart of many project failure modes.

And while I am on the topic of reducing overhead, I would really like to abandon the template approach to documentation.  I get the point of templates, and in the past templates have helped me learn, but checklists are a much more effective tool than templates and make for less overhead

I specifically want to abandon the parts of templates that repeat the same shot over and over again so the repetitive and incidental details can be cleared out of the way, and so that important information can be added. Remember white space?  I want a crisper and clearer message.  I want the readers to engage with the content.

Picture of the PMO manual care of Celeste CC @ Flickr

A significant gap in the current standardisation of project, program and portfolio management relates to the senior management functions necessary to effectively manage the projects and programs initiated by the organisation.

Project Management, as defined by PMI, ISO21500 and a range of other standards commences when the project is funded, and concludes on the delivery of the outputs the project was established to deliver.

Program Management focuses on the coordinated management of a number of projects to achieve benefits that would not be available if the projects were managed in isolation. Different types of program have been defined by GAPPS ranging from optimising annual budgets to maintain a capability (eg, the maintenance of a railway system) through to creating a major change in the way an organisation operates.

Processes for identifying the best projects and programs for an organisation to invest in through portfolio management and tracking benefits realisation are also well defined within the context of strategic management, but are generally not as well implemented by organisations.

Finally the overall governance of organisations and its key sub-set, project governance is recognised as essential for the long term wellbeing of the organisation.

Within this overall framework, the element not well defined, that is essential to achieving the optimum benefits from the ‘doing of projects and programs’, is the organisation’s ability to manage the management of its projects and programs.

At the overall organisational level, the management of project management includes developing and supporting the capabilities needed to provide executive oversight and leadership so that the organisation is able to undertake projects and programs effectively. This includes the organisations ability to develop and enhance its overall project management capabilities, develop project and program managers and project team members, implement appropriate methodologies, provide effective sponsorship, and achieve the benefits and value the projects and programs were set up to facilitate.

At the individual department level, the ability to manage multiple projects in an effective way is equally critical. Typically the role of a Project Director, multi-project management differs from program management in a number of key aspects:

• There is limited correlation between the objectives of the various projects, eg a number of design and fabrication projects may each have a different external customer.
• The function is relatively stable and permanent (programs close once their objectives are achieved).
• The primary focus of this management function is resource optimisation, minimising conflicts and process clashes, and developing the project/program delivery capability of the department/facility.

A number of recognised roles such as the Project/Program Sponsor, project governance and PMOs contribute to the organisations ability to manage the management of projects and programs and develop effective multi-project management capabilities, what is missing is an overall framework that supports the ongoing development of these functions to facilitate the effective governance of projects, programs and portfolios.

Peter Morris and Joana Geraldi have recently published a paper focused on ‘Managing the Institutional Context for Projects’ (Project Management Journal, Vol.42, No.6 p20-32), this paper defines three levels of project management:

Level 1 – Technical ‘project management’; the processes defined in standards such as the PMBOK® Guide and ISO21500.

Level 2 – Strategic ‘management of projects’; the overall management of the project from concept to benefits realisation, starting with identifying and validating concepts, through portfolio selection to delivery and the creation of the intended value.

Level 3 – Institutional context; developing an institutional context for projects and programs to enable them to succeed and enhance their effectiveness. The focus is on creating an environment that encourages improved levels of success in all of the organisation’s projects and programs.

The theoretical framework described in Morris’ paper covers the same concepts (but from a different viewpoint) to the technical framework of organisational entities and roles defined in our White Paper, a PPP Taxonomy (and the linked White Papers focused on specific elements of the structure), see: http://www.mosaicprojects.com.au/WhitePapers/WP1074_PPP_Taxonomy.pdf

What developing the PPP Taxonomy identified within our White Papers, and Morris highlights in his paper, is the critical need for organisations to develop an intrinsic capability to manage the overall management of projects and programs. Over the next few weeks I hope to complete two additional White Papers to start filling this gap:
- The Management of Project Management – the institutional context.
- Multi-project Management – the departmental context.

In the meantime, a PPP Taxonomy defines the overall project governance and control framework these two critically important elements fit within.

On reflection, many of the project and program failures identified in our earlier posts as generic ‘governance failures’ are likely to be shown to be directly caused by the absence of systems designed to ‘manage project management’, this is still a governance failure but now the root cause of some of these failures may be able to be specifically defined.

This is an emerging area of thinking, you are invited to download the White Papers and post any thoughts, comments or disagreements, as well as make use of the ideas to help improve your organisations. There’s a long way to go, at present there’s not even a clearly defined term for this aspect of project governance/management……

You've heard the phrase "All models are wrong: Some are useful," by George Box, a chemist who taught himself to be a statistician.  My takeaway from this is that all models - and that is everything written down in all management texts and training manuals everywhere - is that the model is a lens to look at a problem through.

When I was an undergraduate at university studying marketing we were discussing the Marketing Mix.  "When launching or developing a product..." the lecturer said, "pay attention to Price, Promotion, Product and Place..."

I sat there thinking.  I didn't have corporate experience and this didn't make sense.  It just seemed to simple and to pat. (Four Ps!)  I was trying to learn this stuff by applying it to the bar and restaurant jobs I had.

How can I apply the four Ps to the restaurant?  We can't move it, especially me as a waiter, so the distribution aspect is a moot point.  Maybe we can change the prices and the menu (product) and sure we could do something to raise the bar when it came to promotion.  But what about the other aspects - the relationships the staff had with each other, the way we interacted with the customers, the suppliers (especially the alcohol sales reps!)

So I said as much to my lecturer; "This doesn't seem to be enough.  Surely you need to think through more than this to launch and manage products."

It was then I got one of the best nuggets of information from that degree.

"It's just a checklist to help you along.  It doesn't give you all the answers.  You have to use your brain to solve complex problems."

I wonder how he remembers the conversation, if at all.

To say that my job has been chaotic over the last 3 months would be a mild understatement at best. I think the late, great Douglas Adams can best sum up the last few months for me:
I love deadlines. I like the whooshing sound they make as they fly by. Back about 3 months ago, I went into a meeting with my department's VP, expecting to walk out with 1/3 fewer team members and 1/3 less responsibility. I was overloaded as it was and had been told my job needed additional focus on a single, strategic project. What really happened was I walked out with 33% more team members, 50% more responsibility and an entirely new reporting structure. Needless to say, I was a bit surprised, but pleasantly so.

This role has been a lot of fun and includes a lot of additional challenges, all of which are in the direction I want to be taking. Its kind of funny that the things in my job I least enjoy (although I do enjoy all parts of my job, its just that I enjoy some parts more than others) are the ones that are most related to my old role. Nothing bad there at all; I just really enjoy the new stuff I'm getting to do.

But along with all those additional challenges come the realization that I can't do it all; that I can't be everywhere at once. Not that I could before, but the realization is just more obvious now than before. I'll be the first to admit that I'm stressed out, often frazzled and in major need of additional sleep. My mind is racing all the time and my focus is fractured more than a glass vase dropped from the Eiffel Tower.

Which is why this blog post, about the effects of being 'busy' rang so true to me. There were a few lessons that popped out at me from reading this:

First, if you're going to be the best at what you do, be prepared for a LOT of repetitive work. That doesn't necessarily mean filling out forms or shuffling paper, it means spending the majority of your productive time being productive, not just going through the motions. This is hard; it requires drive, determination and all kinds of overused and poorly understood buzz words.

Second, you've got to focus on that work. This is the part of the article where I realized that my analysis skills were atrophying from lack of use. I've spent the last few months in meetings 75%+ of my days. That's not necessarily a bad thing, but it does mean I have less time to spend in focused practice on my actual role.

Yes, much of what is accomplished in those meetings is also part of my new role. One of the things that I enjoy about my organization, especially compared to some really dysfunctional former employers, is that we actually seem to accomplish things in meetings. Wasting every hour of the day in useless meetings really stinks, so I know I'm fortunate to not spend the majority of my time that way now.

Which is where I come to the next lesson of this article: attitude. There have been times, especially during those meetings I feel are rolling around in circles, where nothing really gets accomplished, that I just want to storm out and 'go get some real work done'. This rolls over into my non-work life as well. My evenings have been filled up with processing email that wasn't even looked at during the week. I'm a firm adherent to the Inbox Zero philosophy, so a box with dozens of unread emails makes me twitch like crazy. Its something I just can't help but comb through, no matter how much I would rather be reading a good book (or writing on this blog).

And this brings me to the last point, one not brought up by the authors of the study, namely that being great requires sacrifice. If the 'average' players in the study practiced their instrument 2 hours per day and the 'elite' players spent 6 hours in study, that's 4 hours the 'elites' could have spent elsewhere, but chose not to do so. Being great, or at least doing great work, means not doing non-great things.

I think it is this last point that is what is the hardest thing for me personally about my job. I am thankful that I get to spend my time doing a lot of good things; I just wish I got to spend more of my time doing great things.

So that, in a very wordy nutshell, is exactly why I haven't been spending time on this blog in a couple months. I've missed you all, Better Projects readers. I've missed discussing topics near and dear to the hearts of those of us who do projects. In short, I missed trying to work out how to be great with you all. Lets not be apart so long ever again. I won't promise not to stray for short times, but I do promise to always return.

Whenever you hear the word 'constraint', your mind is probably like mine and you picture a set of handcuffs. You want to do something for your stakeholder, but because of some limitation, you are unable to deliver to them what they really need.

If you're passionate about what you do, this likely frustrates you. What you really want, more so than anything else, is to exceed their expectations, delivering them the most perfect solution in the world. When you are unable to do that, you probably feel some resentment, not toward your stakeholder or yourself but to whoever imposed that constraint on you.

But it occurred to me during my drive home today that maybe we've all got the wrong image of constraints in our heads. Maybe, instead of bemoaning the limitations that constraints put on us, maybe we should learn to embrace constraints as a good thing. Don't believe me? Lets think about a couple types of constraints and see if a shift in viewpoint could change the way we approach a situation.

Lets say that one of your company's rivals just released a spectacular new product that has instantly made your company's products look obsolete. The finance team has done a few calculations to show that revenue projections will slip by 25% by the time your next new product is released that will return the market to its previous parity. Your product development team has started on a project to create that new product, but is months if not more than a year away from completion.

At this point, you've got a problem. Marketing suggests changing the target market. The sales guys are in favor of slashing prices and moving more units. The production group screams in protest; that they can't keep up with orders now, much less at larger volumes.

You're asked to figure out what could be done to keep the company going until the next big product is done.

First, you recognize a time constraint. The project team needs a year to get a totally new product out to market; one that will, you hope blow away your competition... but your company doesn't have a year to wait. The right question to ask in response to this type of constraint is what can be accomplished quickly that can, if not return the market to parity, to at least get your product to be more competitive.

Its time to start looking for easy options: change the product's color, add in cheap bundles to increase the value of the product, look for opportunities to co-market the device with related products. In short, its time to start thinking of what you can do within a reasonable period of time and not what you can't do with all the time in the world.

Next, you recognize a cost constraint. If finance is projecting such a dire sales slump and your company doesn't have the free cash to keep running at the current cost structure until your new product can turn sales around, its likely you won't have the staff or budget to finish that project in the projected year. If your company cuts staff, the project will take longer. If the budget gets cut, your quality is likely going to suffer.

One way to combat a cost constraint is to figure out ways to mitigate the loss in sales. One way to do this is to offer incremental improvements in your current product that can be delivered in a very short time frame. Change that analog display to a digital one. Reconfigure your site layout to remove confusing features so the user can focus on what is really important to them. Put together a list of the things consumers most dislike or would most wish to see included in your product, prioritize them into a list and determine a strategy to make those things happen.

Last, what about a resource constraint? What if your company's huge project is pulling in all resources while other products of lesser importance fall by the wayside. What do you do when what you are responsible for is having all its resources pulled into a big resource black hole?

You can look for other resources, but you're not likely to find them as the company has already realized its not going to have the money for the big project, much less your small one. You know you've got customers using your small product daily, but they're not getting the support your sales team promised them.

It can be painful, but sometimes your best option is to simply embrace the constraint. Maybe the more time you give to the big project, the faster it reaches completion and the sooner it is your resources come back to working on your project. There are times when all you can do is give in to the constraint.

So what constraints are you dealing with in your organization? How are you dealing with them? Let us know down in the comments!

Back in June of last year, I wrote a post entitled A new Facebook Use Case where I suggested that what FB really needed was a translation utility for comments. Called it.

One of the members of my QA team recently said something about me that made me smile. It wasn't that the comment was some kind of over the top suck-up or a snarky jab, but something that was a subtle reminder, in the midst of a sentence on an only vaguely related topic, of why I get up and go to work every day.

He said I was the only person he knew who loved their job.

The sad part is, I don't think he's far from wrong. I do work with several people who I know do love their jobs and it is clear from my daily interaction with them that their passion for what they do comes through in every conversation, every email and every line of code.

Its people like this, those who think of what they do as craft, who inspire me. I'm lucky; in my current job, I'm fortunate to have many of them who work with me. In my career, I've worked with people who are all over the spectrum when it comes to intelligence, motivation, perception, knowledge, wisdom and taste, but rare has been the person who really has a passion for what they do.

Passion is fleeting, but when it is really intense, its something that has you and not the other way around. Its something that I don't think you can fake; its either present in what you're doing or its not. The quality and the responsiveness of your work is directly correlated to exactly how passionate you are about it.

Even though I crossed the line years ago from individual contributor to manager, I still make it a point to regularly go back and do some business analysis work just to keep my skills sharp. Strangely enough, every time I sit down to do a bit of light analysis on a project, I can't help but remembering why I love this kind of work so much, why it fits me so much. Simply put, I get to make a difference for someone (or as I am fortunate enough to do, for millions of someones).

Given that passion, it probably shouldn't be a surprise to any of you that I obsess about projects. There isn't a better way to illustrate this than to realize that for two years (minus the last 4 months), I've been regularly writing on this blog. That isn't easy, especially with a crazy workload, long commute, a 2 year old and a small bit of socializing. Obsession over this topic is something that drives me, not the other way around.

Obsession is a powerful thing that John Gruber and Merlin Mann nailed. Listen to the audio in the link on this page as these are two guys who really understand what it means to take obsession and give it voice. Their obsessions are different, albeit related, to mine and I strive to have a voice that is as strong as theirs. In particular, pay attention to Merlin's discussion of writing about Jawas. Brilliance.

One of the things writing on this blog has helped me with is to find my voice. The last couple years have helped me refine what I really feel is important in a project and the direction I think projects will take in the coming decades. Technology, especially in the mobile space, stands to make a radical shift in how we elicit, document and analyze requirements.

The biggest change, in my mind, will be using video in the requirements process, especially agile processes. We can already do this today, but mostly its done by making some kind of prototype or slide deck, narrating over top of it and letting your remote users get a feel for what it will be like to use some kind of application. Pulling all that together into a produced video takes lots of time and planning. I don't think this will be how we do it in 20 years.

I see our business users watching someone failing at a process, pulling out their pocket communication devices (we better not be calling them phones then!), snagging a video of the incident, tagging spots in the frame, adding some text or commentary on top of the video, emailing it to the project team and waiting a few hours (better yet, minutes!) for the adjustment to the system to be made.

Or how about the stakeholder using that pocket communication device to make the adjustment themselves! Instead of creating only the tool used by the person performing the process, why not create the next great app that is used to create the next next great app?!?

Its ideas like this that really get me excited. My obsession is going full speed and my voice is coming along. I hope you all can say the same.

I have been over editing Wikipedia again.  This time on Functional Requirements.

Yes, it's the poor quality that revolves around the Requirements and analysis topic that drew me in.  Wikipedia's content in this space is a classic example of the plumber with leaky pipes syndrome.  Each time I see it I just can't help myself.  I have to edit.

But this time I am stuck.

My question for you dear reader is this;

Where does the idea of the Functional Requirement (as opposed to just a plain ol regular requirement) come from?  What is the origin story of this mystical term?

And while I am here, can you share your view on what the essential elements are that make a requirement "functional?"

Thanks in advance,
Craig

Stakeholder analysis tends to be an underdone activity in most projects.  There seem to be a number of reasons for this including social and technical ones.

Next month we are going to have a lunchtime session at work on stakeholder analysis so I did a little research on the topic and came up with a list of useful ideas.  They are posted below with some links.

I am thinking about:

• What does stakeholder mean?
• What boundary conditions help define who is and isn't a stakeholder
• Why analyse stakeholders?
• Techniques for identifying stakeholders?
• Techniques for analysing stakeholders?

Frameworks & thinking models

• The power/influence matrix
• Mapping stakeholder via KRAs
• Ranking stakeholder needs
• Networks of influence among stakeholders
• Integrating different analysis models
• The stakeholder circle model (more examples) from Mosaic 

In October 2011 we were persuaded to switch our Australian Yellow Pages advertising from print to on-line media, based on a shift in sensis’ overall direction. The package and price offered was good.

The process of sensis staff creating the advertisement took several weeks rather than several days despite me supplying a complete set of text for the advertisement (but I was assured there would be no bills from senses until the work was done). Delays in completing the work and publishing the advertisement cut out all sales opportunities pre Christmas 2011.

Before the advertisement was live, we had received a bill for the work that at the time had not been done contrary to earlier promises. A written objection was lodged in early December. To date no action has been taken on this written complaint by senses apparently ‘the complaint is in the queue….’ But this has not stopped their credit department following up on monies that were billed for work not done – a potential breach of the Trade Practices Act.

Dozens of phone calls later, in mid January 2012 the situation remains:

1. No one from senses has contacted me (apart from the credit people)
2. The advertisement as created by senses is incorrect and inaccurate and has not been corrected despite numerous telephone calls
3. I’m now being billed monthly for an advertisement that is wrong and does not reach our specific market – we are refusing to pay this bill as well
4. No information has been provided on how to manage the advertisement and its on-line content
5. Telstra/sensis management continue to hide behind call centre staff who have generally been more then helpful as individuals but are helpless when faced with internal bureaucracy and indifference

To add insult to injury, the on-line form for contacting sensis in writing has been defective since December 2011 and every telephone call takes over 30 minutes ‘on-hold’ before contact is made with the call centre staff, who listen to the complaint, log the call and escalate the problem again so that nothing happens.

My strong recommendation to any small/medium business operator is to do almost anything with your on-line marketing budget other than wasting your time with the incompetent systems created by sensis. You may be lucky to get things 100% right first time otherwise forget any notion of customer services – based on my experience, as far as sensis is concerned anything they do is good enough and you should be grateful, even if as a small project management training company, you get listed as a miner.

Maybe in 2 to 3 years time the glacial bureaucracy within sensis may have worked out how to implement on-line systems that are responsive to their customer’s needs, until then the cost of the time you will wast trying to deal with their processes will be 5 to 10 times the cost of any bill for the actual advertising.

The Planning Engineers Organisation (PEO) has re-launched under the sponsorship of Athena Project Services Ltd.

The PEO is focused on recognising and promoting expertise in planning, scheduling and project controls whilst also encouraging and facilitating the development of new entrants, whether old or young! As such, the PEO offers a membership scheme that provides enhanced levels of access and facilities with the PEO in return for advancement in the knowledge base, levels and length of experience and general standing within our industries.

The PEO is looking to promote expertise in planning, scheduling and project controls, and encourage participation from all levels of ability, including those that are associated with our discipline by way of providing support services, software and employment opportunities. Consequently, membership is open to all planners, schedulers and project controllers, or those associated with project time management, from across the world at the following grades:

• Fellows: Restricted for those individuals with greater than 15 years experience in planning/scheduling or those, who in the opinion of the Organisation, have made a major significant contribution to the field of project time management. This grade of membership carries the designation FPEO.
• Members: This grade is for full time planners/schedulers and project controllers who have at least 5 years project time management experience, and entitles the designation MPEO to be used.
• Associate Members: For those planners/schedulers and project controllers with less than 5 years experience in project time management, or for those whose work or business is associated with products and/or services that are related to project time management. This entitles the designation APEO to be used.
• Student Members: For those studying planning/scheduling and project controllers who would benefit from access to the Organisation’s information and website.

For more information and to join see: http://planningengineers.org

James led a project team that was to investigate and address improvement opportunities for the online sales channel for a financial services organisation. The sales process was mapped and charts put up on the wall of the call centre, where most of the back office work was done.

Subject matter experts from the call centre were asked to inspect and comment on the chart, and to nominate suggestions and improvements. The analysts stood back and made o recommendation. Their contribution to the conversation was to elaborate and explain the diagrams and their notations, and to make corrections as frontline staff observed variations between the model and reality.

The operators identified several bottlenecks and activities that yielded little more than customer or staff frustration. The analysts captured the issues and documented them, later reporting them back via updated models.

By the time the documents had arrived two weeks later the frontline team had already taken action to streamline their process and optimise it for customer experience. Sales had already risen and without any further action the project could well have been called a success.

Charts are a great way to visualise complex information. The following chart may explain some aspects of my life…

However, care needs to be taken in the assembly of data in a chart The following data is Northern Hemisphere centric.

Correlation is not the same as causation!
The source is http://ilovecharts.tumblr.com/ – a blog focusing on project management charts of all types.

The WordPress.com stats helper monkeys have prepared a 2011 annual report for this blog. We would like to express out thanks to all of the viewers and commentators and look forward to continuing the debate in 2012.  Happy New Year everyone!!

 

Here’s an excerpt:

The concert hall at the Syndey Opera House holds 2,700 people. This blog was viewed about 22,000 times in 2011. If it were a concert at Sydney Opera House, it would take about 8 sold-out performances for that many people to see it.

Click here to see the complete report.

Melbourne’s Swanston Street is undergoing a major upgrade to create a primarily tram and pedestrian precinct. This includes new tram stops, but the new Swanston St. stops are dangerous.

The new tram stop outside of Melbourne Central is probably one of the most dangerous pieces of public architecture produced in the last several years. The design ignores basic building standards established for over 100 years and incorporates a small ‘trip’ line of around 4cm in height in the middle of what is otherwise a flat walking area.

The almost invisible ‘trip line’ before the yellow paint line was added.

Steps and kerbs should be a minimum of 10cm in height (preferably 15cm or 6 inches) so walkers can clearly see the change in level. The shallow trip line incorporated into this design is too low to notice but big enough to catch anyone walking normally. I have no idea how many people will need to fall and then sue the Council for negligent design before this dangerous ‘feature’ is corrected but you can guarantee there will be many accidents and near misses on a daily basis.

Another view of the tripping hazard.

What is tragic is the apparent inability of the designers of this tram stop to learn from similar stops created in other locations in the network or from published design principles. This type of ‘tripping hazard’ was a major consideration in the Bourke St. Mall design a couple of years ago and an elegant solution was developed.

Even without this experience, there is plenty of information available that clearly shows it is dangerous to put a small ‘trip line’ at right angles to the direction of travel of most pedestrians. Good design suggests the ‘trip’ is either eliminated by a small change in level or protected by a hand rail.

This ‘feature’ has apparently been deliberately included in the design to keep the pedestrian footpath and bike lane differentiated by having pedestrians ‘step down’ into another zone. A great idea but the same separation effect could easily have been achieved by using a couple of well placed bollards or even a painted line or change in surface texture – the focus on one aspect of safety without looking at easily learned lessons on another has created a hazard that will cause serious injury to many people if it is not quickly corrected.

Unfortunately a few cents of design effort to review and ‘learn’ appropriate lessons will require $thousands to fix now the stops have been built. The danger has obviously been recognised with a pretty yellow line now painted along the length of the trip line (which it totally useless if you cannot see the ground for people). My guess is nothing further will happen until the council’s insurers force the issue after receiving a barrage of insurance claims. Getting designers, bureaucrats and politicians to admit they have screwed up the design is next to impossible. But until this happens ‘enjoy your trip’ will have a completely different meaning in Swanston St.

Photographs copied from http://treadly.net/2011/12/01/swanston-st-the-upgrade/

One of the themes running through several of my recent posts is the importance of effective Governance. Both organisational governance and its sub-set project governance.

Good governance is a synonym for ‘good business’, structuring the organisation to deliver high levels of achievement on an ethical and sustainable basis. This requires the optimum strategy and the right approach to risk taking supported by sufficient processes to be reasonably confident the organisations limited resources are being used to achieve the best short, medium and long term outcomes.

Project governance focuses on the portfolios of programs and projects used by the organisation to deliver many of the strategic objectives. This process focuses first on doing the right projects and programs constrained by the organisations capacity to undertake the work – Portfolio Management; secondly, creating the environment to do the selected projects and programs right- developing and maintaining an effective capability; and lastly systems to validate the usefulness and efficiency of the ongoing work which feeds back into the selection and capability aspects of governance.

 

Within this framework, portfolio management is the key. Strategic Portfolio Management focuses on developing the best mix of programs and projects to deliver the organisations future within its capacity to deliver. This means taking the right risk and having sufficiently robust system in place to identify as early as possible the ‘wrong projects’, so they can be either be reframed or closed down and the resources re-deployed to other work.

It is impossible to develop an innovative future for an organisation without taking risks and not every risk will pay off. Remember Apple developed the ‘Apple Lisa’ as its first GUI computer which flopped in the market, before going on to develop the Apple Macintosh which re-framed the way we interact with machines.

Apple Lisa circa. 1983

Obviously no organisation wants to have too many failures but good governance requires ‘good risk taking’. Apple had no guarantees the i-Pod and its i-Tunes shop would succeed when it started on the journey of innovation that has lead to the i-Phone, i-Pad and Apple becoming one of the largest companies in the world based on capitalisation. As Richard Branson says – ‘you don’t bet the company on a new innovation’ but if you don’t innovate consistently, obsolescence will be the inevitable result.

The balance of project governance focuses around creating the environment that generates the capability to deliver projects and programs effectively, effective sponsorship, effective staff development, effective and flexible processes and procedures, simple but accurate reporting and good early warning systems to identify issues, problems and projects no longer creating value (a pharmaceutical industry saying is that if a project is going to fail it is best to fail early and cheap!).

Good questions outrank easy answers! Every hour and dollar spent on governance processes is not being spent on developing the organisation. The challenge of good governance is to have just enough reporting processes embedded in an effective culture of openness and accountability to provide an appropriate level of assurance the organisation’s resources are being used effectively; whilst at the same time allowing innovation and development. Restrictive and burdensome governance processes are simply bad governance – they restrict the organisation’s ability to achieve excellence.

To help organisations understand these key governance processes we have updated our two White Papers on the subject:
Corporate Governance: http://www.mosaicprojects.com.au/WhitePapers/WP1033_Governance.pdf
Project Governance: http://www.mosaicprojects.com.au/WhitePapers/WP1073_Project_Governance.pdf

For more discussion around the subject of governance see the previous posts on this blog.