I thought I would share another of the ways that I use mind mapping, to create a project plan. Mind Manager (my tool of choice) really lends itself to this because you can export a map to a Microsoft Project and synchronise changes. Although I don’t use the sync feature...
I have just posted about how impressed I am by the OneNote team, and I especially like it when they share details of how the team uses the product themselves to push the boundaries of their processes. In this extract of a long post, Chris describes how they use the...
In some recent discussions I have been introduced to the concept of “productive friction”, which is an effect that’s created when team members with a diverse background get together. It happens for example when people from different cultures or academic disciplines or companies work together to solve a problem and it increases the level of innovation. John Hagel describes it in his book The Only Sustainable Edge and in his Article in the Harvard Business Review.
This recent article in Newsweek describes the effect, and gives some practical and simple advice on how to take advantage of it in your projects:
What they found was that the most successful teams did two things right. First, they attracted a mixture of experienced people and those who were newcomers to whichever field they were in. That’s not surprising–the need for fresh blood has long been recognized as an important ingredient in success. The second criterion, though, was far less obvious. What successful teams had in common was at least a few experienced members who had never collaborated with each other. “People have a tendency to want to work with their friends–people they’ve worked with before,” says Luis Amaral, a physicist at Northwestern …
Andre has this simple and easy to interpret model for classifying people in business:
It’s a lot easier to interpret than many models I have seem.
Although I am more of a solution manager than a project manager I have managed 30 odd projects in my time and a fair few programmes. I have gradually developed a dislike for formal methodologies and templates because of their tendency to prevent the team from thinking. That said I think there are some key management skills that every project team needs, but I have rarely seen described very well. This book looks like it is my sort of style, it in my Amazon favourites in case anyone wants to buy it for me.
Dave Pollard has a good introduction to corporate blogging, here. Dave’s work is consistency good and he also tends to get great comments which complement the posts.
Eric, builds nicely on my last post on “Information Overload” and provides some nice links. I particularly resonated with the idea of “shutting down” in the face of overload (burn out):
Have you ever found yourself emotionally shutting down in the face of a daunting project list and an overflowing e-mail in-box? I have. The Air Force calls this Task Saturation and it can manifest itself in many ways. Some people hyper-focus on their email and new-mail alerts to the point where nothing gets done.
David and I made posts on Saturday and Sunday about the UK researcher who found that email distractions can cause a drop in IQ.
Fellow productivity blogger, Bert, from Open Loops, posted an excellent comment about how the military helps its pilots extract themselves from overwhelm before they have to extract themselves from their wreckage:
This has certainly happened to me a few times when I have been on major programmes and just unable to get my mind around what to do next. In these circumstances I tend to take the following steps:
This is the first in a series of articles about Programme Management. Many of the things I am going to say apply to project management and to management in general but Programme Management is my focus. I need to start by setting the scene.
My experience is enterprise IT infrastructure programmes, so that’s what I will be talking about. By Programme I mean a collection of projects with many dependencies between them. By IT Infrastructure I mean all the common IT services that a business needs, desktops, portables, file, print, directory services, communication, collaboration and coordination services, systems management etc, you get the idea. On my biggest programme, we had approaching 90 different server types so I won’t list them all.
Anyway onto the first topic:
“What does he do? The importance of top down Journal keeping to programme communication, coordination and team spirit”.
Why you may ask did I pick this topic first?
· because almost no one does it
· because it can make a huge difference for very little cost
· because communication and collaboration and coordination are key to any programme and journals help with all three
· because I happen …
I have managed a lot of IT Infrastructure projects in my time, and a couple of smaller programmes. I have also keenly observed the management of several large programmes as a Chief Architect. This article is written from this perspective.
Some initial observations:
The following are a set of Article Titles that I intend to write over the next year or so; they give you a good idea of the issues I think are important:
Users don’t know what they want!.
I have developed quite a few systems, and worked as an architect and systems integrator on many more and it’s always been pretty clear to me that in general users don’t know what they want. Even if the user takes the trouble to write a specification, in the end it won’t meet their requirements for at least one of the following reasons: