There is a terrific book called First, Break All the Rules by Marcus Buckingham and Curt Coffman.  They talk about people having super-highways with certain abilities, and it is the job of the manager to identify those super-highways and align them with the jobs that need to get done.  I have found this to be true in problem solving as well, and the Enneagram gives us clues as to who may have a super-highway in a given area of the problem-solving process.

The first step in the problem-solving process is describing the problem itself.  Do you know anyone who is good at this?  Number 1 of the Enneagram describes a style often characterized as the “Perfectionist.”  This type of person has a keen sense for how things “should” be and knows with precision what is not right. This type will often keep lists of all the things that are not correct.  What better resource for the problem-solving team than to have someone who can list off all the problems? This is a sure way to get the conversation with the team going to clearly describe the problem.

In similar fashion, each style of the Enneagram contributes to a step in this problem-solving process: the 2 delivers the resources to help the team solve the problem; the 3 provides the creative, out-of-box solutions; the 4 and 5 provide the analysis of the ideas, both from an emotional and logical point of view; the 6 develops a plan for a risk-balanced solution; the 7 enthusiastically promotes the plan; the 8 drives the plan to completion; and, the 9 restores harmony after the changes are implemented.   The facilitator in possession of this framework can promote the team’s adoption of each style during the process, and can look to those who are naturally gifted in a given style for leadership during that phase.

Another Enneagram tidbit that I have picked up is that the hardest style for each of us to adopt is the style one number higher than our core style.  The implication of this is that it is easy to get stuck in your area of strength and not move forward to the next step.  There is a well known cliché that describes one instance of this, “Paralysis by Analysis.”  Imagine that your team is particularly strong at analysis.  The team may tend to play to this strength and be reluctant to move to the next step.  It is important for the facilitator to acknowledge this and ensure that the analytical leaders pass the baton to the planning leaders to maintain progress during the initiative.

After reading First, Break All the Rules, I was left wondering how to identify the right people for the job. In other words, how do I figure out each person’s super-highway? In facilitating problem-solving initiatives, I found an answer to that question in the framework of the Enneagram.  Each of us brings a particular strength to a problem-solving initiative, and the strong team will embrace all the styles and allow each to provide leadership during the problem-solving process.

Technorati Tags: enneagram, Leadership, problem-solving, shared leadership

And, while you will find the steps of that problem-solving approach in the ELSIG blog, I include them here for your reference:

1. Problem – Goal: List the problems, define the goals
2. Team: Build a balanced team
3. Ideas: Brainstorm ideas for solutions
4. Analysis: Analyze the ideas
5. Proposal: Prepare a promising plan
6. Advocate: Present the promising proposal
7. Implementation: Implement the plan
8. Debrief: What worked? What didn’t? Start again.

Also, in the previous blog, I promised to explain how I found this problem-solving process.  As the title of this blog indicates, I derived this from the Enneagram.  For those of you not familiar with the Enneagram, here is a good place to learn more: http://www.enneagraminstitute.com/

I have been studying the Enneagram for about 8 years now. I have found the Enneagram to be a powerful tool. Each number on the Enneagram defines a mode or style of human behavior. The Enneagram says that there are 9 core modalities. It goes on to say that while people can operate in different modes, we each have a core mode that governs much of our behavior. Myself, being the skeptical scientific type, I had to test this supposition.  And, test it though I may, I have not found an instance yet where the model does not work well. The Enneagram has enabled me to have a better understanding of myself, my family, my friends and my colleagues, for which I am very grateful.

The Enneagram labels each mode with a number from 1 to 9.  The number itself is not very descriptive and will not detract from the rich description that each mode deserves.  A label, such as “Perfectionist” or “Skeptic,” does start to pigeon hole, so many Enneagram explanations try to avoid doing this. I had wondered why the numbers are in the particular order that they are.  During the course of my studies, I came across a brief comment that said, in essence, the sequential order is the order in which humans naturally solve problems.  After learning this, I started to observe that many of the problem-solving methods that we commonly use, the scientific method for instance, do follow this same pattern.  Fascinating!

You will have already noted that the problem-solving process that I have outlined has 8 steps and not 9. This is a modification that I made in order to make this approach suitable for consumption in the corporate environment.  After step 3, the Idea Brainstorming step, it is natural to analyze each idea.  The Enneagram says that there are two sides of analysis, the emotional analysis (4) and the logical analysis (5).  Not wanting to venture into the realm of asking a group of director-level leaders, “How does that idea make you feel?” I opted to combine both sides of analysis into one step that I simply call “Analysis.” That being said, no matter what you call it, the feelings do come out and must be acknowledged – it is a natural part of the process.

Okay, so now you know how I derived this problem-solving process, and you have been introduced to how you can tie each step in this process back to a core human-behavior modality as described by the Enneagram.  This understanding gives us the foundation to think about sharing leadership during the problem-solving process. The implication is that people who operate in a given mode will be naturally talented at the activity associated with that part of the problem-solving process.  The problem-solving facilitator can leverage these talents to quickly and effectively navigate through each phase of the process, in effect sharing leadership at each step. I will explore this shared leadership in more detail in the next blog.

I have found one book that describes problem solving using the Enneagram, The Enneagram Personality Portraits: Improving Problem-Solving Skills, by Patrick J. Aspell and Dee Dee Aspell. If anyone has come across other references to problem solving using the Enneagram, I would appreciate hearing about them.

Technorati Tags: enneagram, Leadership, problem-solving, shared leadership

The reason I mention this book to this kind audience of program and project managers is that one type of problem that appears well suited to this problem-solving method is the alignment of a product development process itself.  Let me illustrate a couple of examples where this process has worked wonderfully.  The first is the M&A scenario, and the second is what I call the “teen years” of a startup company.

Example 1: M&A

I worked at PalmOne, a company that was the combination of two companies, Palm and Handspring, each with a mature product development process and each process different enough so that teams familiar with one were confused when working with those familiar with the other.  You can imagine the frustration and finger-pointing that occurred as some folks fought over the same roles and other roles were left unfilled. Both sides were confident that their product development process was adequate, and neither side wanted to change. But, change they did.  This problem-solving process focused the energies of all these smart people on problems (not the people) and leveraged their many talents to create and implement solutions for the problems. Within 8 weeks, leaders in all groups that participated in product development, from both Palm and Handspring, were in agreement as to how PalmOne would develop products.

Example 2: The Startup “Teen Years”

Those of you who have worked at startup companies may have experienced that phase in the growth of the company at which the company has grown beyond the scope of the generally like-minded founders and their close acquaintances and has gotten to the stage that requires it to draw in talent from other backgrounds and experiences.  I call this the “Teen Years” since it seems to occur when the number of employees is in the teens.  Also, the behavior of the company is a lot like a teenager, with an “I can do it myself” attitude and a company culture that can be characterized as a kaleidoscope of moods and personalities.  Fortunately, the company staff are adults, and they appreciate the need for aligning the manner in which they are all going to work together.  In this situation, too, the problem-solving method works very well, focusing the team on problems and drawing upon their various backgrounds for ideas on which to develop a work flow suited for their size and their unique needs.  Yes, even the teenager can be satisfied.

What is this process? Where did it come from? And, how can it possibly “herd cats” as advertised. In the next blog, I will outline the process itself.  For those interested in reading ahead, you can find the unfinished book in blog form on the Engineering Leadership Special Interest Group (ELSIG) blog site:

http://sdforumelsig.blogspot.com/search?q=matt+schlegel

You will want to read the oldest posts first.

I have told some folks how I discovered this approach to problem solving.  I will write about this in the next blog. In the meantime, after reading the ELSIG blogs, I wonder whether anyone sees similarities between this approach and other approaches that you have seen or used? I would appreciate your replies with your thoughts on this.

Technorati Tags: enneagram, Leadership, problem-solving, shared leadership

In the first two parts of this series we saw what the mechanics are of introducing processes and how processes can be tailored to your project(s). So now you’ve got the perfect process, but you’re still not meeting timelines or quality and performance objectives ! Why ? More often than not, this is because of the tangled web of dependencies our unsuspecting project teams get caught in.

You can try your best to anticipate and manage dependencies thru dependency trees, network diagrams, etc. But what do you do about the dependencies you don’t foresee. The curveballs that come at you from nowhere. How much slack do you build into your schedule ? Do you compress your schedule to accomodate the dependency ? The answer is .. sometimes there’s just no good answer.  You just have to accept defeat and suggest the unthinkable… extend project timelines.

Project teams most often don’t manage their dependencies well because they don’t do periodic big-picture views of the project. Its easy to get hung up on task management, so much so that the overall project may have veered off course and become susceptible to new dependencies. The most problematic phases are the detailed design and implementation phases. These phases are likely to introduce so much unforeseen change to a project that you have to watch your back constantly.

After having been burnt by this problem a couple of times, I started to schedule regular project reviews that focus on the health of the project as a whole, in addition to the more frequent task reviews. So, as an example, in one project, I had the immediate project team review the tasks every week, and had a more elaborate overall project review every month. Such an eye-opener for so many people ! There’s nothing like an in-your-face presentation of overall project status, stats, issues and dependencies to drive home the point. It makes the team more watchful of their actions/decisions. It makes the outside community more aware of the course the project is taking, and encourages feedback so new dependencies can be identified early. It makes the executive team aware of the due diligence and support required. You can choose the frequency of these reviews based on the length of your project, but make them a necessary step.

How do you manage project dependencies ? How often do you communicate ? I’d love to hear your experiences.

1) Organization-wide processes that only work for certain project types. Would you use the same hammer or spanner for different DIY projects ? Probably not. It’s a good idea to publish best practices for different types of projects, so you can adapt your process to your project. 

2) Overly cumbersome process elements that make the process a burden on the project team. Heck I’ve seen even well-meaning project managers short-circuit such processes to keep their projects on track. Lightweight processes make for systematic application because the process actually helps the project without weighing it down.

3) Defining rigid processes that have been imposed upon project teams. This makes the team feel like the process is more important than people.  Take the time to understand the personalities involved, and the kinds of challenges you might have by trying to apply a cookie-cutter process to varying work styles.

Common sense you say ? Too true. However, time and again project leaders make the same mistakes and then wonder why ‘the perfect process’ didn’t work.

Work out various process best practices and put them up on a board at a visible location such as the office kitchen or near the water cooler. Put the process up on a WIKI page.. anything to encourage a healthy discussion of all the improvements you’re trying to make. Encourage feedback and iterate through improvements so people know they are being heard. Change is inevitable and its best not to fight it.  

Some projects can follow waterfall approaches, and some require Agile (or Agile-like) iterations. But more and more, I am starting to see hybrid processes in play, particularly, when a project requires a rich feature set to be delivered to a customer, and collaboration is key in getting the requirements nailed down.

For one such project instance, the project team had the requirements and architecture work happen with  waterfall processes all the way up to design signoff with the customer. Implementation was however planned into Agile integration cycles, each iteration starting with detailed design leading up ultimately to QA and integration. When all the implementation was complete, we then switched to waterfall again to stage, document and deliver the release.

One size does not fit all ! Be creative, collaborative, and keep your processes simple and nimble. As mentioned in part I of this series, ensure your project team is vested in the process you pick and your executive team is willing to support it. Regardless of the process you pick, it is important to keep good communication, perhaps just vary the frequency of that communication based on your processes. I’d love to hear examples, comments, suggestions, etc. from you all.

I was once asked by the CTO of an engineering organization to help him design the “RIGHT” project process for his engineering team. I was a brand new employee with the company and was surprised he was entrusting me with this lofty task. He said he understood this would take time, but he hoped to see incremental progress. The existing processes weren’t working. The team had failed release after release to deliver what was considered a quality product on time. So, the CTO said to me, “LET’S TRY TO FIX IT !”.

I wondered why he asked me, a mere Project Manager in the grand scheme of things, to turn the tide. Was this some kind of test / joke / tactic to serve some other purpose ? No, it wasn’t ! He told me he made such a choice because he wanted -

• someone with a fresh pair of eyes on the events. Really, someone who hadn’t become a part of the flawed process yet, so is able to step back for a bird’s eye view but dive deep when necessary.
• someone at ground level who doesn’t intimidate the engineering team, and is able to rally people around a common purpose
• someone in a job function where the communication and organization abilities exist to make such a cross-functional initiative possible

What an interesting approach to the problem ! Instead of imposing a process, he wanted his people to work towards it and become vested in it through their project manager/leader. Project leaders often make good process architects because they know the stakeholders, the environment, and the tools available to set the right things in motion. The CTO also said, “Let’s fix it !”, which indicated I wasn’t alone in this endeavor, that I had his support, and that we were on the same team.

Here are a few suggestions on how to define and introduce project process changes (really, just like you might run any project) –

• Take the time to orient yourself. Understand the vision of the executive team and the metrics involved.
• Get to know the engineering team and the current processes. What works and what doesn’t ? Every project team member has a different approach to their task at hand. How do they work, communicate, collaborate, estimate their tasks, etc. Is the team geographically dispersed ?
• Understand the customers and the nature of the releases. Do the contractual obligations to the customer impose rich feature sets and long release cycles ? Or is the engineering team in continuous development mode where a feature is released as soon as it is ready?
• Get to know the product, its major and minor components, its strengths and weaknesses.  How much testing does it need and how elaborate is its deployment procedure ?
• Identify your ‘quick wins’ – the items that will get you the biggest bang for your buck, so you can show incremental progress to all parties. (Thx to a good friend, a successful project leader herself, for suggesting this once upon a time). Process changes are difficult to roll out. You’ll find yourself taking baby steps sometimes, and making giant leaps at other times.
• Involve different people in the definition of different problems and implementation of their solutions. This will ensure people are vested in the process even if they don’t immediately see the big picture.
• Use visual representation. Put up the ‘big picture’ process chart on a board in a central location at the office. Use color post-its or some such to mark the wins separately. This is so people see there is a method to this madness and that their efforts are helping it all come together.

How would you go about introducing process change ? I would love to hear your comments, suggestions, gripes, etc.

photo by nutmeg66

My first two guest posts were about the intersection of Knowledge Management and Project Management; in this post I would like to talk about what I think are some of the peculiarities of Knowledge Management projects.

For the most part Knowledge Management projects are just like any other projects, tasks have to be delineated, risk managed, status reports given, you know the drill. What I think is different about knowledge management projects is that they tend to touch on more of the organization, often they are enterprise wide and no one wants to own them in part because they don’t understand them.

If an owner or owners are identified and a management change occurs it can throw the whole project into question. The success of the project often comes down to influence and sustained management support from one person at least for the first little while, until the business case is proven. Although even then I have seen successful projects shut-down because the new management team didn’t understand the value of the initiative.

There are often multiple stakeholders on both the business and IT side, with IT taking a lead. IT taking the lead is a problem. Technology is an enabler and a critical part of the project, but the project needs to be lead by the business. Technology ultimately needs to enable business processes, not be some extra “nice to have.” This only happens if business takes the lead and ensures that the technology is supporting business processes, not hampering them. When business leads they focus on the people and process part of the equation, and work to provide a balanced solution, not a technology-centric one.

The value of Knowledge Management is often hard to measure, in tangible ways. Connecting people to the knowledge they need to do their jobs is often described as an opportunity cost. How can I measure something if I don’t know the value of having it? For example, what if I “recreate the wheel” because I didn’t know a colleague in another region had already “created the wheel”? You never know you’ve recreated something, so can’t measure the cost/benefit.

One project I did was like that, a team in Asia-Pacific had found a solution to their ISO 9000 document management needs, it had taken them 6 months. Another team in North America was starting out on finding a solution to the same problem. I connected the two teams and the second one took 3 weeks to get their documentation sorted out because they could re-use what the first team had done. If the connection hadn’t been made, the second team could have taken six months or even longer to resolve the issue, but would never have known the difference.

Those are what I think are the main oddities about Knowledge Management projects, they aren’t reasons not to do them, just issues to be aware of and monitor closely throughout the project lifecycle.

After Action Review, by betseymerkel

In my first post about Project Management and Knowledge Management I spoke about Collaboration, in this second post I will talk about after-action reviews.

After-action review also known as a project snap-shot, lessons learned, or any number of other names is an important Knowledge Management activity to complete at the end of a project. They don’t have to be long and cumbersome, in fact they shouldn’t be. Taking a few minutes to summarize key decisions that were made, things that went well, things that should be done again, things that didn’t go well, and things that shouldn’t be done again is an important learning tool for project team members and for future teams–if they decide to go and look for lessons learned before starting a project. This is especially true for inexperienced project teams/members, i.e. they should be looking for lessons learned before starting a new project.

Some project managers will argue that there is no point in doing after-action reviews that no one looks at them and that may be true. I have gone to many Knowledge Management conferences in the past and at the ones I have attended recently it surprised and frustrated me that many of the case studies seem to repeat the same lessons learned, in fact I wrote about it in an earlier blog post. That doesn’t mean that after-action reviews shouldn’t be done, it means that project managers and others need to remember to go and look for lessons learned and not fall into the “not invented here” trap of thinking that no one has done a particular activity before or that if it hasn’t been done by them/their organization there is nothing to be learned from other’s experiences.

Even if no one outside of the project team uses the lessons learned it’s important for the project team to do the analysis. Sometimes things are happening so quickly on the project that team members need to take a few minutes once the project is done to tie everything together. Once all the tasks are complete they can see the big picture of what actually happened and the consequences of certain actions and decisions so they can learn and do things differently next time, make new mistakes rather than repeating the same ones time and again. I know I like to make new and improved mistakes rather than the same old ones.

photo by Claudio Branch

When Loyal first asked me to guest post on this blog, I said sure without thinking about it too much, I knew that Project Management and Knowledge Management went together, that’s what I do after-all as part of any project I do. Then I thought how am I going to explain it and make it interesting so that people will actually read to the end? I thought about this much harder and in the next 2 posts you’ll get my thoughts on the intersection of Knowledge Management and Project Management.

First though, a definition on Knowledge Management, I broadly define Knowledge Management as connecting people to the knowledge they need to do their jobs. This knowledge can be tacit or explicit (not written down or written down), so you might imagine that there are lots of tools in the toolbox, activities like mentoring programs, and Communities of Practice, to document management, and social networking, to name a few.

I won’t debate whether you can manage knowledge; we have been having that debate on my blog for the last few weeks, so I will leave that discussion there.

The first area of intersection between Knowledge Management and Project Management that I thought of was collaboration. Collaboration is not a new idea, or activity, but it is a knowledge sharing activity, so I thought it fit well in the intersection. What has changed about collaboration in the last 10-15 years is the part technology plays. As a project manager I want to know the about the tasks my team is working on, I also want them to know about what I am working on, e.g. the status of issues I’m trying to resolve, and upcoming deadlines. It used to be that project teams were primarily collocated and so knew what was going on because they saw each other every day, now teams are virtual, working in different regions and countries and time zones and languages, so collaboration and how best to share knowledge has to be thought about a little more.

Teams can have regular meetings, but time zones can impact that day-to-day knowledge sharing that used to happen because everyone was in the same place. Technology can help replace that: collaboration technology that includes task lists, email, document and content management, teleconferences, instant messaging can all help.

The question then becomes which methods to use and how to organize it. This is where some Knowledge and Information Management thinking come into play. As a project manager I need to talk to my team about how we want to work—understand their connectivity, and their location, as well as determining a common language/dictionary. If I’m working on a cross-functional, cross-regional team it is quite likely that each member will have a slightly different understanding of terms and processes so creating a common language and understanding becomes key, this will evolve as the project progresses so it is important to be vigilant about identifying disconnects throughout the life of the project and not to let them side-track the project progress. For example, if team members are disagreeing about how to do something it is quite likely that they have a different understanding of whatever the point of contention is, as a project manager I have to identify that and work to resolve the misunderstanding. I once worked with a manager who repeatedly told me that there was no data migration for a portal project we were working on and got quite angry when I tried to understand why, it took me two months to get through her anger and help her understand that in a portal project data is documents and other pieces of unstructured data, not debits and credits like the financial systems she was used to dealing with.

Project Managers lead many of the behaviours of the team, so if I use the technologies and processes that I’ve put in place there is a higher likelihood that the team members will too. I once worked with a team on a project, there were team members around the globe and we were good about using the technology and keeping each other up-to-date, at one point my manager put me on another project and replaced me with another project manager. The new project manager didn’t like technology and didn’t use it. The team stopped using the technology and the project failed.

I think that’s enough about collaboration and the intersection of KM and PM for now, next time: After-action reviews.

photo by *spudballoo* via Flickr

It had all the earmarks of a disaster, a real career-sinker of a project. And here was my old friend and former colleague calling me up enthusiastically, on the phone: “Hey Lisa, we need a Technical Project Manager for this start-up I’m working for, in Redwood Shores… you’ll love the project and the team. It’s a fun environment and they treat consultants really well here – honestly.” Okay, Ted, what’s the kicker? “Oh, by the way, we’re short-staffed – you’ll have to code, just 20% of the time. It’s just lightweight GUI stuff; no big deal.”

“Ummm, Ted – I haven’t coded in over 6 years, that’s forever!” I moaned. “I’m a project manager now. Cannot do – seriously.” “Oh, you’ll be fine; I’ll show you the ropes – it’s like riding a bike,” he assured me.

Oh jeez. Well, you can guess – I was between gigs and it did sound intriguing. I had enjoyed working with Ted at Autodesk, and I thought, “How bad could it be?”

At any rate, after cramming on programming languages for two consecutive weekends and hosing one of my laptops (thank goodness it was a dinosaur), I showed up at the company. Ted was right, it was a great environment – just 32 people in the office and everyone was about the same age and at the same stage of life. We also had an office in Toronto and in London, making for 3 different development streams (counting Redwood Shores) that needed to be integrated in order to produce the company flagship product, a suite of software applications in the interactive TV space. All of the major customers were overseas in Europe and Asia.

So my major contribution was managing the overall program and pulling together an integrated schedule for Development, QA, etc…, controlling the budget, risk management, all the usual Project Management activities… and I also had to create the screens/UI for one of the applications.

I have to say that this was one of the most interesting and challenging contracts ever. I learned something new every day from the technical wizards, many of whom had worked at Oracle and Peoplesoft (they all went on to work at Yahoo and Google some years later.) By the end of the job, I was coding Oracle servlets with the best of them. It still remains as a high point in my career as a technologist.

But I digress…

What Ted hadn’t told me on the phone, and what I discovered a few weeks later into the project, was that the last Project Manager had quit – and not on good terms. He was “disgusted and frustrated with the state of affairs,” one of the developers told me. I soon found out why. We would have conference calls and the developers in Redwood Shores would sit around the conference table with their arms folded, feign listening politely, and make passive/aggressive comments. The folks in Toronto and London, on the other hand, talked up a storm, making jokes. For Mike and Tom, our lead developers in the U.S., the levity of the foreigners was just not funny – they had managed to lock the code branches they were working on, once again, so that the Redwood Shores team was unable to perform integration. What seemed on the face of it just some idle banter and typical team storming was becoming a real issue.

I decided to take the bull by the horns. I managed to get CFO approval to get the two non-domestic teams onto U.S. soil on a “Kumbayah Roadtrip,” as Ted put it – but I was betting the farm on the visit. I arranged for team-building activities, such as the now-famous “Trust” exercise of running and leaping into your teammates’ arms and trusting that they won’t let you fall. We went bowling and played miniature golf (yeah, I know, it’s corny), and had lots of working lunches and dinners. We even went to see a play at the Curran Theatre in San Francisco. Somehow, at the end of the ten days, we had managed to bond and get past both the cultural differences and the quirky personality traits – all three teams had finally started to function as one, which was critical to both project success as well as the corporate bottom line.

What happened during the Canadian and British teams’ visit was truly amazing. Mike and Tom were able to air out their frustration with the overall sloppiness and lack of protocol with the development processes, and the Canadians and British took their criticisms to heart. I did have to play referee and adopt a “Gentlemen, get into your corners” attitude, but it was well-worth the initial less than optimal discussion.

It’s easy to misunderstand and make communication faux pas while on the phone, and not in person. It’s a lot harder to ignore someone when they’re physically sitting across from you at the table… and your body language can give you away in a way that doesn’t happen over a telephone wire. And it’s definitely easier to dismiss and malign another team member’s efforts when you haven’t met them in person.

Project Managers can set the tone and help facilitate the tough discussions when they are needed. We can help smooth things over and remind folks not to take things so personally, and to try to pursue solutions as a team. Perhaps most significantly, we can provide real business value by working to build bridges and relationships between team members, and ensuring that the sum of the parts is greater than the whole so that the project is delivered on time, within budget.

Technorati Tags: attitude, Budget, communication, control, Corporate, criticism, Customer, Environment, integration, interest, joke, Language, Listening, management, people, PM, process, Relationships, Risk, schedule, Success, Team, Teambuilding, Teams, time, trust