Archive for May, 2014

May 30, 2014

Send Your Iron Triangle To The Scrap Heap

Or maybe to a ranch somewhere, where it can be used to call folks in for supper. Or dinner. Whichever one happens at lunch time.

So – here’s the deal: We keep talking about the iron triangle, or triple constraints as a bedrock of project management – and it’s not true.

Sure – understanding your timeline, and your budget (which these days also includes resources because you can buy just about any expertise you may want) and your feature set is important.

 

image

 

But those three things aren’t useful in the way they once were, not especially for software projects.

In the old model, it was super expensive to set up a server. To pay someone that understood routing. To find someone that understood the difference between an inner and outer join. And so on.

And in the old model, either it all worked, or you didn’t have anything.

Because of those two things – the iron triangle made a ton of sense – if you bent any part of the triangle, something else had to give. Since creating software was super expensive and super time consuming – this was a handy way to frame a project.

My, how times have changed! You can have a server setup in a few minutes, at the hosting location of your choosing, and it costs pennies on the hour.

Shouldn’t we change our mind about the usefulness of the triangle? I think we should.

I suggest that we relegate the triangle to the basement – you might want to drag it out and use it once in a while – but you don’t want it cluttering up your work.

And then replace it with a much simpler diagram – it’s about decision making, releasing to the public, and adoption.

You have 2  axes:

  • Rapid, informed, and devolved decision making
  • Rapid and iterative release to customers

If you achieve both of these – your outcome is adoption (you ARE releasing what customers want, right?)

image

But if either of those axes tilts (slow decision making/slow release) – you don’t get adoption. Someone else gets there first:

It’s not the big that eat the small, but the fast that eat the slow.

A bit more about decision making. Your business owner shouldn’t be involved in the how. And they should be involved in the what only to the extent that they can describe it out loud. Asking them to weigh in on your CSS schema is silly. So you want to devolve decision making as much as you can – get your execs to tell you why, and what in general, and then let them get back to running the business while you and your team get to work.

And that work should be fast and iterative. Show, don’t tell. Let your team build something that works, and show it early and often – and you can course correct quickly. Even better – show it to your actual customers and find out what they think.

What do you think?

May 28, 2014

Make Your Next Project Manager Hire an English Lit Major

I’ll disclaim right away: I am an English Lit major and also a project manager.

(That also means that when this post descends into broad generalizations, I’ll know that I’m intentionally using hyperbole.

Consider:

When a lit major says “I don’t know” what they really mean is:

“I don’t know yet, but I learned how to know in school.”

When a lit major says “That seems familiar” even though nothing looks familiar, what they really mean is:

“I learned how to recognize patterns that cross boundaries – so this looks familiar, so I can help solve this problem.”

When a lit major says “I’ll send a status report”, what they really mean is:

“I might send it as an haiku, but everyone will read it and know what it means.”

When a lit major says, “I can explain that”, what they really mean is:

“I’ll find a way (allegory, storytelling, comparison) to help you grasp a technical concept in a way that allows you to make a great decision.”

When a lit major says “It’s okay if we disagree”, what they mean is:

I learned in school that there are oft more than once answer to a question – so I don’t need to be right, so long as we are moving forward together.”

When a lit major says that success is finishing the project, what they mean is:

Following a method is easy but doesn’t guarantee success. Success is defined by finishing, not starting.”


I could go on, but I won’t. Not imitating James Joyce or Charles Dickens here.

Here’s the deal though: People with a lit degree make better project managers, because their eduction was about learning, not about doing. Project management isn’t about following a software development cycle, keeping a schedule, managing a budget. Those are the least important parts of project management (needed, don’t get me wrong). But merely keeping track means you can be successful at . . . keeping track. So what? You want a fast learner, someone with endless curiosity, someone with great communication skills, someone that can get through a ream of reading material and know what is important, someone who grasps and uses context.

What you need, then, is a Lit major!

 

 

May 23, 2014

7 Mile Race Planning – Waterfall or Agile?

Okay – this is going to be a stretch, so add salt!

I’ve been thinking a lot lately about how things actually work in the real world – not how they look on paper, or in your PMP training or your Scrum training – but you know – the real world.

See – I’m an avid runner, and last year needed to get speedy for a 7.4 mile race (part of a relay that I do every year). My team came in 2nd place the year before, and we thought we might be able to win last year, but it would require peak performance from everyone on the team. So I wanted to get as ready as possible.

If I make some gross generalizations about using Waterfall to get ready for a race, I might have planned and executed like this:

  • Assess race distance
  • Review schedule, costs, timeline
  • Put together a training plan based on the 7.4 mile distance
  • Pick a per mile time goal, and start running at that pace 12 weeks out
  • Train for the race near my home
  • Race day

And if I took a page from the Agile book, it might be like this:

  • Decide to run the race
  • Start running the race
  • Stop for a new pair of shoes
  • Notice that I wasn’t fast enough
  • Decide that I really wanted to run a 3 mile race instead (at a slower pace)
  • Tell my team that we weren’t going to finish first

Okay – you can see that I’m being silly here – because the truth is that I borrowed a bit from each methodology to run my most successful 7.4 miles. Here’s what I did:

  • I put together my team – made sure everyone was available, knew what they were doing for the relay, had time to train, and could make travel and gear arrangements. This already sounds like waterfall.
  • I created a scorecard for my fitness level: body weight, hours of sleep, weekly mileage, fastest mile, best 8k recently. This also sounds waterfall like – but I didn’t use this as my plan – I used this to start my training iteration. Agile-fall, anyone?
  • I took immediate action: I needed to be a bit lighter, and I needed to visit the track far more often. I did – and based on my results – starting adjusting my training plan. Agile, all the way.
  • I realized that I wasn’t running a general 7.4 mile race, I was running a very particular one. And I could go and practice there, so I did. Even though I’ve run that course multiple times – I’d never really thought about the course in particular. And thinking about it in particular was huge. It turns out that just about the 4 mile mark, the gentle downhill turns into flat as a pancake. When I compared my previous runs along the course, I noticed that I slowed considerably here, while maintaining the same effort. It taught me that right there, at that spot, I had to pick it up – I had to increase my effort. And to do that meant changing my training plan. More agile, don’t you think?
  • I changed my last few weeks of speed training, so that I was running my very fastest track efforts AFTER 4 very hard miles of running.  Again – agile takes the upper hand.
  • I went back to planning mode though – I spent a ridiculous amount of time reviewing the course elevation, my speed and my heart rate – and used that to update my race day plan. I even wrote each half mile time and heart rate on a card and taped it to my wrist. A little of each – waterfall and agile.
  • Race day had a series of hiccups. Our cyclist double flatted, so instead of starting my run in first place, I started pretty far back. And the race director (and friend) suffered a heart attack. That meant that my carefully planned warmup wasn’t going to work – I warmed up, I waited, and then (not knowing about the flat tire) – couldn’t stray very far from the starting line. I resorted to jumping up and down, push-ups, and other calisthenics to see if I could still be ready for running at my top speed from the very word go. Agile takes the win here.
  • Once I started – I stuck to my plan though – I hit each half mile right where I was supposed to, and when the going got flat, I got going. But since I’d raced the course 3 times in the last 3 weeks – I knew just what to expect. Waterfall, perhaps?

Okay – that was a bit tortured. But you can see where I’m headed. At their best – each methodology has a lot to offer. But at their worst, neither would have led to success for me on race day. My running project needed a mixture of careful planning  before I started, iterative work along the way, and then sticking to a plan (that was tested in advance) on race day.

My most successful tech projects are like that: You plan some, you do some, you re-visit the plan. You focus on the actual work, not just on initial assumptions. You find out what is happening in the real world and adjust. And when it comes time to launch – all things being equal – you go back to your launch plan.

 

 

 

May 21, 2014

Show Don’t Tell

I used to work in theatre. And while I was either working in the office or in the pit orchestra – I was around the actors often enough to hear them say, time and time again, “show, don’t tell“.

That’s because showing works better – far more effective to juggle than to talk about juggling.

I feel the same way about consulting – it’s easy to fall into the trap of telling and not showing (in the case of consulting – I’d switch that out to say “not doing”). But doing is far more effective – and most of the time my customers want me to accomplish something, and it isn’t talking. Or a document. Or yet another recommendation.

That doesn’t mean that you have to do all of the work yourself, but it does mean that you have to work and produce. If you’re on a website project – I think it best to go far past strategy. Deliver some primary research, a UX framework, a gap analysis between what tools your customer has and the tools they need.

You can see where I’m going here – do as much of the actual work as you can. You’ll be happier, and so will your customer.

 

May 20, 2014

I Win, Because The Scope of Work Says So . . . Right?

Uh . . . No.

If your project is going south, and you think you can right it because it’s “in the scope” – you may win a battle but you’ll certainly lose your project.

See – even *if* the folks that signed your scope of work read it all of the way through, and even*if* they understood that when you said “mobile friendly” you meant responsive and not that you were building a mobile app, and even *if* the person that actually signed has come to a meeting or two . . . – you’ve lost.

Don’t get me wrong – you should write a terrific scope of work, and you should do everything you can to make sure that the person signing it understands what they are going to get, and when, and at what price.

But don’t be fooled: your scope of work depreciates like a new car rolling off of the lot, and it’s almost immediately worth far less than you think. Timing, money, people, features – those all change quickly. So if your project is going off the rails, don’t think that your scope of work will save you.

What you do need to think about, from the first client meeting to the final delivery, is about your relationship with the person that signed:

  • Do you tell them the truth?
  • Do you meet/communicate regularly?
  • Do you educate them (appropriately) at every turn, to help them become a better stakeholder?
  • Do you let them know early when something seems to be going awry?

If so – great. You won’t need that scope of work. But if you’ve neglected those things, your scope still won’t save you.

May 19, 2014

What Makes Great Project Management Software?

I won’t make you wait for the answer: the best project management software in the world is the one that everyone on your team uses.

Yep. That’s it.

Sure – we could argue all day long about the relative merits of a bunch of tools:

  • Microsoft Project
  • Jira
  • Basecamp
  • Daptiv
  • Sharepoint
  • Microsoft Excel

And a few hundred other tools. I’ve used each of the tools listed – and you know what? I think they are all terrific. Sure – some have more widgets. Some are easier than others to setup.

But here’s what I’ve learned: if your whole team isn’t committed to using the same tool, it doesn’t matter how good the software is. You’ll end up in  project management hell – you know, the one where you manage your work in one spot, and report out somewhere else. So you have the real data. And then the stuff that you converted to Excel. Which you pasted into a PowerPoint deck. And which someone sent around a few weeks later to additional stakeholders. And then you have a firestorm, because the $ or the date or something else is no longer accurate.

Not all projects are created equal, either – so you might choose one tool for a certain type of project, and another for a different kind. One of the common mistakes agencies make is to assume that the same tool always works for every project.

(It’s similar to the template mistake. You know the “we *have* to use this template for our scope of work. Actually – no you don’t. You might have a short list of things that you must include in every scope – like the price, and some legalese, and a few other things. Cut loose a little – you want your customers to read the scope, not admire the format).

So – what tools do you use to manage your projects? The same tool every time? A different tool, based on project type? Does your entire team use the same tool? Enquiring minds would like to know!