I have a semi-allergic reaction to sounds bites that appear to lack thought before propagation. Its a part of my general complaint about modern politics. It used to be the case the politicians had to be able to hold an... Dave Snowden http://www.cognitive-edge.com

No man putteth a piece of a new garment upon an old; if otherwise, then both the new maketh a rent, and the piece that was taken out of the new agreeth not with the old. And no man putteth... Dave Snowden http://www.cognitive-edge.com

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)

Any talk about water won't rival the feeling of this swimmer who just jumped in (picture by Horia Varlan on Flickr)

Or: Why talking about an experience is no substitute for the experience.

This week I led students of Latin America Studies at Georgetown University through a Net-Map exercise (Thanks to their teacher Patricia Biermayr-Jenzano for organizing this!). They chose their own questions (a wide range, from personal family disputes to crime reduction in a Latin American small town) and started mapping it after a brief introduction. All of them had read some of my papers and case studies before, so one of the things that struck me in their feedback was how different Net-Map looked to them when they read about it and when they actually did it. Some of their comments:

“I initially was skeptical because I did not understand why a simple activity could be a method for creating social change.  Net-Mapping allowed me to view the world differently.  Granted, stepping back and analyzing the degree of influences in our lives should be a natural process, but it is something that we do not do visually.  By doing this activity and visually seeing our influences, it breaks the ice and fosters dialogue in a non-confrontational way.” 

“The level of sophistication of the tool far exceeded my personal expectations.  I was skeptical not because of the materials involved in the process (paper and pen) but because of the difficulty in determining who influences whom in most of the research in which I have participated.  I think the greatest advantage of the Net-Map system is the ability to look at an activity from a variety of levels.  My group worked on the scale of the individual, but seeing the work of the other groups made it obvious that Net-Map can be transferred to an organizational level or even perhaps to an international level.” 

“I had never done net-mapping or anything alike before. Honestly, when listening to the explanation I thought it was kind of a game. However, after doing the exercise I actually realized the great value it has. Using this hands-on method of visualizing problems or activities I believe is really useful. I believe that great ideas and problem visualization can be seen that may not be realized using other strategic methods.”

Yes, I fully realize the irony of this post, because, as I said in the introduction: talking about an experience is very different from experiencing it. So, get some pens, post-it notes and toys, print out the instructions, come up with a question that bothers you and involves many different actors and see what happens if you try mapping it. You might not start out as an Olympic swimmer but rather splash around in the shallow pool for a while. But even that will be a more interesting experience than reading stories about water, wouldn’t it?

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?

This is not the kind of Agile I'm talking about (picture by Double--M on flickr)

Last week I worked with an Agile coach who helps large organizations to move their software development from traditional waterfall programming to adopting agile approaches. What does that mean? Well, waterfall programming means you start out by telling the programmers what you need, then they go and program for a few (or more than a few) months and finally come back with a program for you to use. Now you can see whether you actually knew what you wanted in the beginning and whether the finished product fits. In an agile approach the programming cycles are shortened to weeks and at the end of each iteration stands a good enough product that you can start using and trying out, giving feedback to the programmers so that they can go back to tweak, adjust and make it fit.

One of the great and scary things about becoming agile is that it doesn’t just mean using a different kind of product in the end. But that it means significantly changing processes, power and incentives within the organization. So introducing agile is not just a technical switch but actually an organizational change effort. And this is why my colleague proposed that we Net-Map it.

So at the beginning of a 1 1/2 year project he has just started we met with the three leading managers who oversee the agile implementation for this international corporation. And asked them the simple and difficult question: Who are all the actors who will influence the success of the project (positively or negatively)?

What did we find out? Well, my colleague now has a list of people he wants to invite to the first planning round. And within this list, he knows of a few people who need special attention, e.g.:

• The social integrator, that everyone feels comfortable going to with new ideas or the need for feedback.
• Some actors from neighboring domains who fear that their influence might be diminished by the implementation of agile.
• The strongest driver of the process in the leadership team.

He has more clarity about the drivers that motivate the different people involved and their priorities, especially when it comes to the question: “Is it more important to get stuff done and show results fast or to implement and document processes that others can follow in the future?”

Also, mapping out the whole situation provided a great opportunity to dig deeper into the history of this project, the divisions and people involved and how their past experience with each other might influence their ability and willingness to work together on this project. This specifically is an area where external consultants can easily step on landmines from conflicts they didn’t even know existed…

And finally, working with the project leaders on this and giving them the space to draw a map of their views and experiences, allowing for disagreement and exploration as well as finding a shared core, was a great way of laying the ground work for a longer process of collaboration, getting to know each other better, seeing what their priorities and worries are and reassuring them that we have heard.

I will be speaking to a group of HR professionals on the confluence of KM and HR (webpage). I am interested in the intersections of both business disciplines, and how one might support the other in better managing their organisation’s human capital. The choice of topic is motivated by a frequent realisation in KM projects that success is often dependent on engaging - and having engaged - HR colleagues. There are several areas where I think HR and KM can work together.

In job interviews they identify candidates who demonstrate a propensity to share rather than hoard what they know. They look for candidates who maintain strong external professional networks that can be tapped into for knowledge and information.

In onboarding, they provide a map of what knowledge is critical to their business and where they can be found. Where tacit knowledge is concerned, they broker the necessary connections. They emphasise the employees’ role in updating staff profile and directory. By the same token they also stress “quality in, quality out” for information repositories.

That knowledge management is a line manager’s responsibility is promulgated through job descriptions. That knowledge sharing is an important competency is reinforced through competency frameworks.

In succession planning they help identify what knowledge the next cadre of leaders should possess, and figure out ways to bridge the knowledge gaps. They do this by reducing the responsibilities of would-be retirees and by tasking them to be mentors or coaches to their successors – with the blessing of top management of course.

How else do you think HR and KM can work together?

This is the collection of keyword pairs that appeared in two clusters of people who Tweeted about “Paul Ryan”, the Republican Congressman from Wisconsin who delivered the GOP rebuttal to the 2011 United States State of the Union Address.  This network illustrates the ways that certain word pairs appears only or predominantly in one cluster (colored here Red and Blue) or the other. Terms that appeared in both clusters appear as purple.

Social networks are built from relationships between people.  Keyword networks are built from relationships between words and other text strings.  When two words appear in the same message, sentence, or alongside one another ties of different strengths are created.  The networks that result can illuminate the relationships among topics of importance in a collection of messages.

Markus Strohmaier from the Technical University Graz (TUG) along with Claudia Wagner gave us inspiration in a paper:

C. Wagner, M. Strohmaier, The Wisdom in Tweetonomies: Acquiring Latent Conceptual Structures from Social Awareness Streams, Semantic Search 2010 Workshop (SemSearch2010), in conjunction with the 19th International World Wide Web Conference (WWW2010), Raleigh, NC, USA, April 26-30, ACM, 2010. (pdf)

in which they defined a range of ways two words (technically these are strings, they may not really be words) can be associated with one another.  Words could be linked if they are in the same tweet, next to one another, or sequential among other ways to link terms.

NodeXL has not had any features for exploring the networks in texts.  Now with the addition of a new macro from Scott Golder, it is fairly simple to extract pairs of keywords from collection of tweets.  NodeXL’s Twitter importer can optionally include the content of the tweet that included the search term and this column of text can now be processed itself into a new network based on the ways words appear together in tweets.

This feature builds on the work of several people.  Scott Golder from Cornell started the ball rolling with a simple but effective VBA script that allowed others to build and refine the models of what counts as a tie between two words.  Vladimir Barash added several refinements including support for stop word lists to remove common terms.  Scott then picked up the code again and added a set of features for selecting the nature of the graph and making it easier to select the options needed.

The code for the Keyword Network macro is below.

The instructions to use it take a few steps to complete:

1. Create a new workbook, eg a list of tweets or an import from a Twitter search, whatever. Save it as .xlsm. The m is important. This can be an existing NodeXL workbook.

2. Go to Developer -> Macros. Make up a name; it doesn’t matter because it’ll get overwritten. Then press Create. the VBA window will open.

3. In the big text are that says “Sub whatever() End Sub”, select all that text and delete it. Paste in the contents of the text file below.

4. Go to Tools->Reference. Check the checkboxes for “Microsoft Scripting Runtime” and “Microsott VBScript Regular Expressions”. Press OK. Save the file (File->Save) then exit (“Close and return to Microsoft Excel”).

5. Now go to Developer -> Macros. Choose CreateWordNet and press the Run button.

6. It’ll ask you for a worksheet name, a column and a start-row. Then it’ll create a new worksheet with the edgelist in it.

The edge list is not directed (there isn’t really a concept of direction in “co-occurs”) but is weighted. Each pair is weighted by the number of times it appears.

This version also includes options for edge creation.

First, it is now possible to suppress edges of weight=1, which is helpful in getting rid of a lot of garbage.

Second, it is now possible to defined edges by adjacency or co-tweeting. Given a tweet of words “w1 w2 w3″ adjacency will give edges w1-w2 and w2-w3, while co-tweeting will give edges w1-w2, w1-w3, w2-w3.

For edges defined by adjacency, you may choose directed or undirected edges. So a tweet of “Marc Smith Marc” (for example) would generate the weighted directed edges Marc,Smith,1 and Smith,Marc,1 while the sole undirected edge would be Marc,Smith,2. That is, for undirected edges (where ordering doesn’t matter) the words are alphabetized.

An illustrated guide:

Start with a NodeXL workbook with a column of text for either Vertices or Edges (or any column of text).  Here we have the tweet text of a recent Twitter Search Term network query.

Select “Developer” from the Excel menu and create a new Macro.  I take the text of Scott’s macro and paste it here, replacing everything else in the code buffer.

Note the selection of Tools>References> needed to run this macro!  Select Microsoft Scripting Runtime and Microsoft VBScript Regular Expressions 5.5.

Running the Macro:

Scott’s macro presents a series of dialogs to the user (I believe we could do this in a single dialog when we revise):

First we specify the worksheet in the workbook containing the text column to process:

Next we specify the column containing the text to process:

Next we specify the row in which the text starts in that column:

The macro will copy an edge attribute forward if specified (note, I think the *last* attribute for any AB pair is what is reported).

The user is asked if the results should omit the singleton edges, which can be useful.

Edges can be defined as co-sequential or co-cell: ie. ABCD can generate AB, BC, CD or AB, AC, AD, etc.

Users select if they want the edges to include their reciprocal (i.e. generate a “BA” edge for each “AB” edge).

The result is a worksheet with word pair edges and the weights of their frequency of occurrence.

This worksheet can then be imported into a separate NodeXL template using the Import from Open Workbook feature:

This generates a keyword network that looks like this:

We will be working on a revised and updated version of this workflow in the coming months.  For example, this is a possible UI revision:

Create Word Network VB Macro Vdb5//

 

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……

The Defense Intelligence Agency’s (DIA) Knowledge Lab faced the challenge of how to move accurate intelligence up the chain of command. Too frequently the intelligence analysis, painstakingly generated by front line analysts, was delayed and often severely modified by a chain of superiors before it reached policy makers who could act upon it. The intervention DIA undertook to enable telling truth to power, was called “Critical Discourse” based on the work of Argyris. The format was to bring together a team of analysts along with their supervisor, to jointly analyze the actual conversations that occurred between members of the team and between team members and their supervisor. Nancy Dixon

Interested in applying social network methods to better understand the structure of your business or organization?

In collaboration with Optimice, I will teach a workshop on Social Network Analysis for enterprises, organizations, and businesses using NodeXL.

• Self-paced e-learning (4 hours)
  • Introduction to Social/Organisational Network Analysis
  • Network patterns and metrics
  • Software tools for network analysis
  • Managing an ONA Project
    
• Module 1: Scoping your ONA Project (2 hour virtual session hosted by Patti Anklam)
  • Determining which business problem to solve with ONA
  • Review of case-studies
  • Determining your questions
• Module 2: Setting up your ONA survey (2 hour virtual session hosted by Cai Kjaer / Laurence Lock Lee)
  • Setting up your survey
  • Working with mailing lists and other lists
  • Creating relationship sets and network questions
  • Previewing and launching the survey
  • Tracking progress and downloading responses
• Module 3: Visualise networks with NodeXL (2 hour virtual session hosted by Marc Smith)
  • Getting started with NodeXL
  • Calculating and visualizing network metrics
  • Preparing data and filtering
  • Importing data from Social Media tools
  • Clustering and grouping

A number of ONA Practitioner Courses are available to suit the timezones of participants located in the US, Europe and/or Asia-Pacific (but not restricted to these regions):

Course Code Date and Time Time Zone Payment OPC-2012-9-EUR 29 February 2012 to 27 March 2012
(Registration deadline is 15 February 2012)Module 1: 13 March 2012 (10am – 12pm)
Module 2: 20 March 2012 (10am -12pm)
Module 3: 28 March 2012 (3 – 5pm)Self-paced to be completed before starting module 1. Europe – London GMT $US 1,599
OPC-2012-13-APAC 27 March 2012 to 25 April 2012
(Registration deadline is 13 March 2012)Module 1: 11 April 2012 (11am – 1pm)
Module 2: 18 April 2012 (11am – 1pm)
Module 3: 25 April 2012 (11am – 1pm)Self-paced to be completed before starting module 1. Asia-Pacific – Sydney EST $US 1,599
OPC-2012-17-US 25 April 2012 to 22 May 2012
(Registration deadline is 11 April 2012)Module 1: 8 May 2012 (4 – 6pm)
Module 2: 15 May 2012 (4 – 6pm)
Module 3: 22 May 2012 (4 – 6pm)Self-paced to be completed before starting module 1. Americas – New York EST $US 1,599

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.

Waltraut Ritter has a scathing and important critique of KM in general and the MAKE awards in particular, taking some pot shots at some of the participating case studies at KM Asia 2011 in the process (scroll down to the 22 Nov entry).

“Knowledge management practices are often narrowly focusing on internal operations and not addressing larger questions about the nature and sustainability of the knowledge driving the organization. There seems to be a separation of KM from the overall business strategy, a general neglect of addressing the larger questions about an organization’s knowledge and how such knowledge may create societal value beyond a company’s financial gains.” She gives an interesting example from Mars, referring to the ingredients in their product Skittles: “Few of these ingredients have anything to do with real food, and one might argue that the industrial food industry contributes to decreasing knowledge about nutrition and food in society rather than contributing to informed decision-making on food. Could the organization use KM to establish a serious dialogue with customers? Develop ideas and products for a global, sustainable food production?”

Important and difficult questions, connected to the earliest visions of KM back in the 1960s. In 1967 L.K. Caldwell wrote an article for the Public Administration Review in which he asked how knowledge management could help ensure that “all relevant knowledge is brought to bear upon the problems that society needs to solve [...] At the very least, the manager of knowledge needs to discover what science can tell respecting trends or objectives that would be socially harmful.”

I've always argued that that Margaret Attwood's The Handmaid's Tale should be added to the cannon of key dystopian novels. Traditionally there are three: Brave New World, 1984 and Darkness at Noon. Of which I think the Koestler is the... Dave Snowden http://www.cognitive-edge.com