Posts Tagged: project management

Main — Comments Off
12
Jan 10

Project Management Trends

Leading Answers has a thoughtful article on Project Trends Every PM Should be Aware Of. My favorite bit:

“The World Has Changed – Why Haven’t Your PM Tools and Approaches?
In the last 10 years many changes have occurred in the world of managing IT projects, yet we still see the same tools and approaches being employed. Is this because they are classic and timeless? Are the traditional PM approaches so successful that they do not need to be dragged here and there following trends and immature technology fads? No, I fear it is more that people are creatures of habit, and the usually more mature project management community, are worse than most at evaluating and adopting new approaches.”

The first thing you must do is admit you have a problem with your project management process. It isn’t the business analysis, coders, or testers that is broken. It’s the process that is broken. Not the people. Once you can admit that, the world becomes much much less stressful.

Main — 1 Comment
17
Nov 09

Maturity Models Have It Backwards

Michael writes:

“As one of the few people who has read the CMMI book from cover to cover, here’s what I think: In process-speak, the notion of maturity is backwards. [...] A mature person is one who is highly conscious of when it’s appropriate to follow rules and when to break them. A mature person is largely self-guided. Only in exceptional circumstances does a mature person need to refer to or appeal to a rulebook at all. In such cases, the issue is that someone believes that the rulebook isn’t working, and in such cases, consensus between mature individuals and organizations—not the rulebook itself—makes the determination as to what should happen next. Mature people know that rulebooks need to be interpreted.”

He sums it up by noting that:

“A mature process should encourage risk-taking and mistakes while taking steps to limit the severity and consequence of the mistakes, because without making mistakes, learning isn’t possible.”

Main — Comments Off
7
Nov 09

Visual Management

Visual Management is one of those things that feels obvious, but isn’t. The idea is that you manage projects, tasks, and other bits of work-in-progress using something visual (ie, not digital). It’s a chart on the wall that everyone can see, that everyone can modify, and is updated regularly.

There was a workshop specifically for Visual Management at Agile 2009 and a subsequent write-up on the presenter’s Visual Management Blog. But don’t be fooled – while this may be gaining traction in more technical areas, this will work for anyone’s project. There are lots of great pictures of examples and is worth your time to browse the pictures even if you don’t read the whole post. I’d suggest starting here.

I’m amazed at how well a non-technical solution can communicate to everyone on (or off) the team.

XQA_9556

Main — Comments Off
5
Nov 09

Plans aren’t sacrosanct

Projects@Work has perhaps the most succinct description of the problem with plans:

“Plans aren’t sacrosanct — they’re meant to be flexible guides, not straightjackets. Agile project leaders focus on adapting to inevitable changes rather than opposing them. In this way, value and quality are the end goals and the plan becomes a means to achieve them, not the goal itself.”

Main — Comments Off
22
Sep 09

Documentation

Jim Highsmith wrote: “Documentation is often the solution to a communications problem that can’t be corrected with documentation.”

I found this to be a good reminder. I mean, the point of documentation is a simple one isn’t it? To convey ideas and intent clearly and without ambiguity. We write it down because we can’t remember long enough or clearly enough, or we don’t trust the people we are working with enough. (“I asked for X” “I thought you asked for Y” “well, let’s go look at the document!”)

If we worked in smaller iterations (with people we trust), our need for documentation would decrease exponentially. With contract thinking (ie, everything must be written down and signed) increases project cost by 30-50%. That’s a lot of waste for a problem that is pretty easy to solve.

I suppose there is a secondary purpose to documentation that focuses on tracking the history of an item. But let’s be honest – how many times do you go back and look at project documentation after it has been released into production? In my experience, the more detailed the document, the faster it becomes irrelevant and unhelpful.

Picture 1

← Older Entries