Search This Blog

28 July 2009

ARSRTM (user stories)

There is two acronyms out there to help guide people on writing effective user stories.  One is the Three C's and the other is INVEST. You can read more about these two mnemonics elsewhere.

I want to introduce you to a new, third one, that I am sure will overcome the other two due to it's snappy acronym.

ARSRTM stands for
  • Achiveable
  • Realistic
  • Specific
  • Realistic (I want to emhasis the point)
  • Timebound, and
  • Measureable
Sure they are a mouthful, but I think they effectuvely cover the ground that the INVEST mnemonic does, and you have the opportunity to double up on realistic to emphasis it's importance.

I thought about jumbling the letters around to make a palin english word to make it more catchy, but, really, without dropping the second 'realistic' I just couldn't do it.

27 July 2009

A Systems Approach to Product and Service Design

Caitlin Johnson from Caridan Marketing Labs is doing some work with Cornell University's online arm, eCornell.  She got in touch with me the other day asking if I'd promote a course they are running there. 
It looks like some good content in the course, and if you haven't been in a classroom for a while, some structured learning won't hurt you.

The course is specifically around the complexities inherent in new product developement.  That's what we do, right?  Define, design, construct and implement complex new systems. 

Anyway, Caitlin has put together a brief on the course for me to share with you.  Here it is.

Caridan Marketing Labs is an interactive and social media marketing firm based in New York City. As eCornell’s marketing agency, we partnered with them to launch a new Systems Design program. Their newest online certificate, A Systems Approach to Product and Service Design is authored by Professor Peter Jackson, Director of Systems Engineering at Cornell University. In six two-week courses, project managers will master a proven eight-step methodology and structured process that can be used to take an idea to the point where it can be handed off for completion.

In working and talking with project managers it has been shown that the projects that are most difficult to manage are usually related to new product and service launches. Scope creep, unclear requirements, and inter/intra team miscommunication can become a recipe for disaster! What some project managers are missing is a proven methodology that will help them to understand how to design and develop products and services the right way from the beginning- and avoid common pitfalls in the process.
In this program, project managers will:

  • Learn a structured methodology for designing products/services the right way
  • Avoid the pitfalls that can lead to “designs gone wrong”
  • Earn a certificate from Cornell University in under three months
This program is aimed at helping to fill a gap for PM's who are going through the frustrating process of managing new products/services.

So there you have the information.  Further course details on the course are here.

Lastly, I am talking to Caitlin about running a competiton about project war stories.  Maybe we can arrange a discount on this course for the best submission?  Details tomorrow.

26 July 2009

Milestones / Signs

Eugenio highlights the fact that milestones are waymarkers, and that in fact it's the work between the milestones that builds our solutions.  That's true. 

Milestones are a point where you can reflect on where you have been and where you are going.  Are you still heading in the right direction?  Are you as far down he road as you expected to be?  What's happenned on the road so far, and what lessons can we learn from our experiences?

In my post the other day I talked about how you can break large tasks down into smaller tasks to the degree that they become a repeatable process.

An example; instead of spending 2-3 months going through a requirements elicitation and definition phase you can break this down to an ongoing process, say of a regular weekly meeting throughout the project lifecycle.

You can still have milestones, and the opportunity to plan milestones around the completion of certain groupings of fucntionality or releases remains. 

What might change is that the milestone becomes less of a marker of what has been completed (say as a percetage of total work, or schedule) and becomes more of a reflection of where you have been and where you are heading.  Maybe it makes for a more eflective session?

24 July 2009


My thoughts about the master-apprentice mode of learning got me searching. I found this diaram showing many of the concepts around the apprenticeship model.

The model is by Herbert Spencer and a larger version can be viewed here.

Did you learn your trade as an apprentice? How was your master?  What do you think about this model?  Do you coach or mentor anyone today?

23 July 2009

Measuring success as an agile BA

A BA I know came to me a while back and expressed frustration of not having specific deliverables in a scrum project.

The typical BA deliverables of requirements spec, UAT plan, change management and comms plans have been replaced with ongoing processes rather than particular documents which represent milestones in progress.

To a large degree these milestones have been replaced by ongoing processes of capturing and refining requirements, defining acceptance criteria and running tests. You end up with many smaller incremental milestones instead of the big few.

I discussed he issue with him until he had talked through his issues sufficiently for his frustrations to be vented and for him to have identified an immediate plan for himself.

Yesterday he came to me and expressed thanks to me for pointing him in the right direction. (The joys of Socratic questioning – I hadn’t even known how I was helping.)

He had come to realise that his measure of success was the same as the developers; increments of working software that has been happily accepted by our project stakeholders.

That’s my measure of success, too.

There are other things I need to do to get this done. Documents and progress reports are a part of the toolkit. So are meetings and conversations with people.

We do these things so that the goals can be achieved. When push comes to shove you prioritise the things that most contribute to your goals. You don’t just follow the process.

Measuring the right things is a real trick, isn’t it? Making people see value in the right measurements is also an important thing to do. Breaking bad habits – in ourselves and others - appears to be part of the job we all face, as we continue to grow in our profession.

This reflection is making me realise some of the problems of the master-apprentice model that many of us learned our trade in. It’s great if you get to learn from a true master early in your career, but what if you are one of the many who miss this opportunity?

22 July 2009


Josh at PM Student points us to a new management tool called Autofocus.  An interview with the 'inventor' Mark Foster is below.  You can read more at Mark's website.

Josh tells us he's going to start using it.  Maybe I should also.  Josh - let me know how it goes.

20 July 2009

Why design matters to the operation of a project team

Tom Peters on the importance of design for service providers (like project teams.)

Is design more important for marketing products than services? 
No. Paradoxically, I believe that design is more important for services. Harvard marketing expert Ted Levitt pointed out years ago that if your product is tangible (planes, boats, cars, pen knife), you need to distinguish yourself from the herd by emphasizing intangibles i.e., service. 

If your product is intangible (banking, travel, etc.), distinguish yourself from the masses by emphasizing the tangible to wit, design. FedEx, for example, stands out on the tangibles strong branding, clean trucks, easy-to-use forms. 

To me a business system, like FedEx's, that works transparently on the surface and offers brilliant simplicity is as much about design as an iMac or a Beetle. If you're a service business, it's important to specifically work on the tangibles.

Why is this relevant to us?  Project teams are professional service firms.  We're temporary, but that's what we are regardless of the nature of the product we are creating.

And for us success is measured a measure of perception over expectation.

You can read more on the topic of how tangibles make our clients happy under the RATER tag.

17 July 2009

Enterprise architecture and business architecture

At the Melbourne BA conference I was asked to sit on a panel discussing what the differences and similarities of these two roles are.  I am not an architect and have not been one in any previous career.  So I wan't neccessarily prepared, and left that dscussion a little disapointed with where it went.

The discussion itself got stuck on how the Zachman framework is a full architectural framework that gos beyond technology.  Yep.  Okay, what next?

I'll throw up a few of my (still unprepared) thoughts here and see what comments I get.
  • Architecture is about designing in future capability, not delivering it
  • The differnece between enterprise architecture and business architecture is only a matter of terminology.  Or is it?  Mabe the business architure is less focused on the technical?
  • If you put up an architecture it becomes the baseline for change, and variations from it have to be justified (to some degree)
  • This means archicture should be an ongoing role and should generallly be flexible and open enough to accomodate new ideas
  • Like anything, context matters a lot
  • BAs are great candidates for architecture roles as they evolve through technology and business design
  • Why doens't architecture drive more business cases?
That last point is one I am curious about from a project perspective.  If architecture is about building capability, surely it should be able to justify investment.  Why is it that (technology) architectural elements are usually only implemented as constraints on projects?

12 July 2009

BA Symposium, Melbourne

Tomorrow I do my talk on how the BA can act effectively in the role of scrum product owner.

I am not very good at promoting myself for these events. Instead I have been enjoying myself hanging out at cafes and restaurants in my old neighbourhood. And seeing friends and family.

So, maybe I'll see you at the Sofitel at 2.30pm tomorrow.  I am guaranteed to be one of the more interesting talks.  I promise.

In September; Canberra, October; Brisbane.

5 July 2009

The Business Analysts as Scrum Product Owner

I migrated my BA Symposium presentation from powerpoint to index cards and a file.  Prezi doesn't read like a book, so a stand-alone online reading doesn't work as well as Powerpoint files, but it sure does look neat.

4 July 2009

BA Symposium, Sydney

I'll be speaking at BA World's BA Symposium in Sydney on Monday about how a BA can migrate into a scrum Product Owner role and sharing some experiences from my life. If you are there drop by and say hello.

(I'll also be at Melbourne the next week.)

The draft of the slide deck is below.  I'll probably be abandoning it though as I want to try out using a tool I saw at a recent Thoughtworks resentation called Prezi.  When I have completed the prezi file I'll try to post it here.

I'll also be sitting on a panel called BA-PM Turf wars.  The theme is as follows;

Ten years ago many organizations had no idea what a BA was! Today they employ many of them! The Project Managers are looking around and seeing a whole new role within a project – one that was sorely missing on many projects of the past. Or was it? Some project managers will tell you that the requirements gathering phase is their job. Some organizations will tell you that the PM and BA are one and the same. Others will bring it the business analyst and not even tell the project management community about them! Let the turf wars begin!

This is a similar theme as Elizabeth's Harrin's BCS talk in September.  What are your thoughts on this issue?  To me it smells like alignment issues again.