From: http://changingminds.org/blog/0902blog/090225blog.htm

Much work these days is packaged up as projects, with plans, resources and time-bound deliverables. Managing projects is a skill as the various risks and issues can easily trip you up. In particular the sheer complexity can cause much extra work and conceal important issues.

Here, then, are four ways of making things simpler by separating out things that need your attention in different ways.

1. Separate rapidly changing things from slowly changing things. This makes changes (and communication about them) easier. For example a strategic plan, which changes little is separated from a rapidly-changing tactical plan.

2. Separate things that require attention now from points of information. This allows a sharper focus on action. For example items that require decisions may be covered first in a meeting, then information discussions continued in the remaining time.

3. Separate planned action from unexpected action. This allows both to be clearly managed and for plans to be revised as needed. For example issues are managed separately from standard project plans, thus allowing both onto the stage.

4. Separate internal project communications from external communications. Internal communications can be detailed, technical, textual and full of jargon. External communications should be focused, brief, visual and use Plain English.

You can also use the principle of separation to create clarity in documents and presentations by:

* Using colour, bold fonts, and other visual contrasts.
* Using lines and physical separation.
* Visual/physical separation into sections, pages, documents.

Enjoyed these rules from Immo Böhm  writing about Software Project Management.

“Nothing is impossible for the person who doesn’t have to do it.” and “You can con a sucker into committing to an impossible deadline, but you cannot con him into meeting it.”

I enjoyed this 2005 declaration from David Anderson:

Declaration of Interdependence

We are a community of project leaders that are highly successful at delivering results. To achieve these results:

• We increase return on investment by making continuous flow of value our focus.
• We deliver reliable results by engaging customers in frequent interactions and shared ownership.
• We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
• We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
• We boost performance through group accountability for results and shared responsibility for team effectiveness.
• We improve effectiveness and reliability through situationally specific strategies, processes and practices.

From: David J. Anderson and Associates

One hack I find useful is to keep people’s extensions next to their names in my IM client.

Sometimes a call is required and I find it useful to have number right there to hand if I need to explain by phone.

Google: Ten Golden Rules – Newsweek – Newsweek: International Editions – Issues 2006 – msnbc.com

“Getting the most out of knowledge workers will be the key to business success for the next quarter century. Here’s how we do it at Google”

# Hire by committee.
# Cater to their every need.
# Pack them in.
# Make coordination easy.
# Eat your own dog food.
# Encourage creativity.
# Strive to reach consensus.
# Don’t be evil.
# Data drive decisions.
# Communicate effectively.

Jerry Weinberg is a legend in Project Management and Consulting circles. Here are his 10 Laws of Trust:

1. Nobody but you cares about the reason you let another person down.
2. Trust takes years to win, moments to lose.
3. People don’t tell you when they stop trusting you.
4. The trick of earning trust is to avoid all tricks.
5. People are never liars—in their own eyes.
6. Always trust your client—and cut the cards.
7. Never be dishonest, even if the client requests it.
8. Never promise anything.
9. Always keep your promise.
10. Get it in writing, but depend on trust.

Conferences That Work | Jerry Weinberg’s ten laws of trust

I am currently crunching through Steve Litt’s brilliant series of books on Troubleshooting. I am hugely into general problem solving frameworks and his Universal Troubleshooting Process (UTP) is one of my favourites.

Today, whilst clearing my backlog on Instapaper I came across this Wired.com piece on legendary design firm IDEO. They use a simply process called “Design Thinking” that they claim is at the heart of their stunning successes:

Practically speaking, the approach isn’t complicated. In stages, it goes like this: firstly, immersion, whereby the designers research the problem by plunging themselves into it – talking to the people they’re trying to help, working with them, interviewing experts. Secondly, synthesis – whereby they gather together their findings and look for patterns. Third, ideation – brainstorming solutions to the real problems identified by stage two. Then comes prototyping, making mock-ups of solutions to try out against the problem. After that comes the product. Only at the end, at the prototyping stage, are judgements made; until then, all ideas are given equal weight.

This methodology is radical in that it differs from traditional approaches to business strategy in two key ways. Whereas in many companies the concept for a new product may have already been based on, say, an idea from the marketing department with a designer later brought in to make it look pretty, design thinking places the designer at the heart of the innovation process. Secondly, the methodology gives a firm framework within which a wider team can work. It takes the cliché of the lone creative mind being struck with genius, and replaces it with a process that a whole team can follow. Creativity, therefore, isn’t a thing that magically appears, but a process you work through.

From: Reinventing British manners the Post-It way – Wired.co.uk

I can see similarities to Ken Watanabe’s simplified problem solving methodology as presented in his best-selling children’s “Problem Solving 101“

1. Understand the current situation current (Immersion)
2. Identify root cause (Sythesis)
3. Develop an effective action plan (Ideation)
4. Execute until solved, making modifications as necessary (Prototyping)

From: http://www.problemsolvingtoolbox.com/

You can also see similarities between IDEO’s framework and Dan Roam’s framework for proble  solving through visual thinking as outlined in “The Back of the Napkin: Solving Problems and Selling Ideas with Pictures“. In the book Roam explores a four stage process for solving any problem with visual thinking:

1. Look (Immerse/ Understand)
2. See (sythesis / Identify patters / root cause)
3. Imagine (Ideation / Plan)
4. Show (Prototype / Execute)

How do these map to the Universal Troubleshooting Process (UTP)?

The UTP shares the core troubleshooting steps with the other three (3, 4,6,7 and 8), but it has some seemingly anachronous and superfluous steps (1,2,5,9 and 10). I say “seemingly” because experience has taught me that the Universal Troubleshooting Process steps are all necessary and in the right order.

It is aimed more at professional, routine troubleshooters and as such addresses the important psychological factors and habits that contribute to long-term effectiveness.

I cannot do this process justice in a few lines, but here is summary:

1. Prepare - This is about having the right attitude and mindset for troubleshooting as well as the required tools, skills and information. For professional troubleshooters (like Technical Support agents) attitude is one of the most important elements in their professional quality and success.
2. Make damage control plan – This is iatrogenic prevention i.e. do not make things worse. If forces you to think of consequences before trying pot luck fixes.
3. Get a complete and accurate symptom description - Here the UTP shares a step with the first principle of the other three (i.e. Look / Immerse/ Understand). In the UTP thi9s is usually achieved by creating a simple block diagram off the problem system so as to understand elements and relationships.
4. Reproduce the symptom - This is part of fully understanding and verifying the current situation. You verify the symptoms and measure them.
5. Do the appropriate corrective maintenance - This step is again targeted at professional troubleshooters. So many problems are caused by bad maintenance and fixed by routine maintenance, that often it is worth running the standard best practice maintenance procedures over the system and seeing of that fixes the issue.
6. Narrow it down to the root cause - This is the core step. Often it is a process in itself as you look from problem patterns, isolate elements of the system and systematically disqualify them as candidates for root cause. Eventually you generate a most likely root cause hypothesis and proceed to step 7.
7. Repair or replace the defective component - Here you generate a plan to test the hypothesis by fixing, replacing or implementing a work-around for the root cause.
8. Test - You now apply your fix and test to ensure the problem is indeed solved. 
9. Take pride in your solution – This is another psychologically important steps to help prevent burn-out and boost morale.
10. Prevent future occurrence of this problem – This is simple operational best practice. You learn from your problems, document your solutions and new knowledge, you modify systems and procedures to ensure the problem does not reoccur, or you can respond quickly and effectively.

This universal troubleshooting procedure has been a vital tool for my team and I in beating some extremely tough problems, sometimes involving desperate customers begging us to fix badly broken massively complex undocumented systems and us successfully finding and fixing the root cause problems in 24 hours where the system designers could not succeed for months.

I also heartily recommend the Dan Roam and Ken Watanabe books referred to above. They are both brilliant and accessible.

There is a good article in Projects@Work about what to do when a risk you chose not to mitigate materialises, and how to handle it.

From Projects@Work – A Guy Named Murphy:

Widely accepted risk management theory says that doing nothing is an appropriate response to some risks. But what happens on a project when you’ve done no risk mitigation and then the risk materializes?

“When you are running a large project and have already passed the project planning phase, the project manager’s core role is managing the performance of people, meeting plan expectations, and assessing the threats to project success,” say Tim Pare and John Kirkwood, managing consultants at PA Consulting Group. “From a practical point of view, there are always a ton of these threats and there is seldom time available to spend on things that have a low likelihood. It is probably more often the case that risk mitigation activities are curtailed, or not enacted at all, rather than pursued for too long.”

Lisa Anderson, president of LMA Consulting Group, also believes that there’s a natural stop to risk management activity. “I’ve led project teams, it is common to have unexpected events and challenges arise. [But] once you have established an effective project team and defined a critical path, stop risk mitigation activity, as it will be a waste of time and resources,” she says.

In fact, these unexpected events are par for the course in project management. “If you have been a PM for any length of time you have run into problems on your projects — especially if they are IT or technology related,” says Bruce McGraw, CEO of Cognitive Technologies, a professional services firm delivering project and program management services, products and PMO tool implementation to commercial and government clients. “In fact, we blame these problems on a guy named ‘Murphy’ which has led to the whole field of risk management, where we try to think of all the things that can go wrong before a project starts. The first step in addressing the worst case is to determine that you have a problem. That is not always as simple as it seems.”

Johanna Rothman, author of Manage It! Your Guide to Modern, Pragmatic Project Management, agrees. As a consultant, she was brought in to help resolve a crisis on a development project where nothing was working and everything had been tried. “[The] project was slipping a week every week,” Rothman says. “The PM had no idea what to do. The project team had no idea. They were trying to integrate a piece of hardware and software, and it wasn’t working.”

Rothman established that the problem they thought they had — no more options — wasn’t actually the real problem. “The developers had been saying ‘We’ve tried everything’ but they hadn’t. The testers were saying ‘We’ve tested everything’ but they hadn’t. I had them build a matrix of everything they’d tried and the results they’d gotten. Once they realized there were holes in the matrix where things hadn’t been tried, they knew how long those tasks would take and we would have another chance to reassess after those tasks were done.”

From the Economist’s Guru section article on Elliott Jaques:

Jaques (1917-2003) decided that jobs could be defined in terms of their time horizon. For example, a director of marketing might be worried about marketing campaigns for next year, while a salesman on the road is worried about reaching his targets for the week. Jaques also believed that people had a “boss” and a “real boss”. The boss was the person to whom they were nominally responsible, while the real boss was the person to whom they turned to get decisions crucial to the continuation of their work.

The sales manager in charge of a salesforce would not have a longer time horizon than the people in his salesforce. So when a salesman wanted a decision on something affecting his ability to deliver to his clients, he would go over the head of the sales manager for that decision. Jaques called this “level skipping”, and identified it as a dangerous pathology in any hierarchy.

He then looked at the time horizons of people, their bosses and their real bosses, and he found that people with a time horizon of less than three months treated those with a horizon of 3–12 months as their real bosses, and so on up the scale. He identified seven different time horizons, from three months to 20 years, and argued that organisations, no matter how complex, should have seven levels of hierarchy, each corresponding to a different managerial time horizon. Jaques’s theory has come to be known as RO (requisite organisation).

This reminds me of the Tolstoy quotation from C.S. Lewis’s “The Inner Ring”:

“When Boris entered the room, Prince Andrey was listening to an old general, wearing his decorations, who was reporting something to Prince Andrey, with an expression of soldierly servility on his purple face. “Alright. Please wait!” he said to the general, speaking in Russian with the French accent, which he used when he spoke with contempt. The moment he noticed Boris he stopped listening to the general who trotted imploringly after him and begged to be heard, while Prince Andrey turned to Boris with a cheerful smile and a nod of the head. Boris now clearly understood-what he had already guessed-that side by side with the system of discipline and subordination which were laid down in the Army Regulations, there existed a different and a more real system-the system which compelled a tightly laced general with a purple face to wait respectfully for his turn while a mere captain like Prince Andrey chatted with a mere second lieutenant like Boris, Boris decided at once that he would be guided not by the official system but by this other unwritten system.”

Projects@Work have an excellent introduction to Agile Project Management: Agile, By Any Other Name…

Agile, by any other name, would still look like modern project management. The value-driven benefits of scrums, stories and showcases have made sense well before the emergence of Agile. And they certainly aren’t incompatible with so-called “traditional” project management concepts and techniques.

…

What are the practices that make up Agile today? The key ones are:

• Develop in short cycle times
• Plan short term (the next cycle)
• Develop only what is needed
• Close collaboration with the user
• High visibility and daily reporting
• Empower the project team
• Test in parallel with development

How do these differ from traditional approaches?If you come from a background of two-to-three-year development projects with a single, gargantuan deliverable at the end, then this may seem like a radical departure from business as usual. But for the vast majority of developers, who are managing projects with timelines in months not years, the benefits of short cycles and multiple deliveries are well known.

Likewise, the impracticality of a detailed long-term plan is also common sense, and most developers would sketch out a blueprint to allow them to plan ahead for resource requirements and other long-lead-time concerns. In fact, there seems to be a risk that nothaving a long-term plan would result in a loss of alignment with business strategy.

The ‘soft’ practices of empowering teams and regular management communication are more a characteristic of modern project management than the preserve of Agile, and certainly they are compatible with a traditional waterfall approach to software development. Well-run development teams do this anyway, and the old days of Theory X management have long gone, except in the most unenlightened organization.

Its a good overview and introduction to the ideas behind the various Agile methodologies and how they are very relevant and useful to “traditional” project management.