Search This Blog

30 January 2012

I don't believe in slipping dates

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.


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?

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.

29 January 2012

The terror of the templates

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

27 January 2012

All Models are Wrong (Part 1)

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.

24 January 2012

I Called It!

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.

19 January 2012

Obsession Times Voice

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.

12 January 2012

What is the Origin of the term "Functional Requirements"

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,

11 January 2012

Stakeholder analysis

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

3 January 2012

Case study: Visualise workflow

Melbourne City Silhouette

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.