The Enlightened Project Manager

I just finished teaching a 3 day class on agile project management to a group if PMs in Cairo, Egypt. The class was one of the outcomes of an agreement signed between the Egyptian Government and the PMI IT & Telecom SIG last year. I’m approaching 10 years of volunteer service with the SIG.

One of the points we spent a lot of time discussing is when to apply agile. I spent some time talking about the sweet spot for agile…projects that don’t have clear requirements, are not huge, have strong user involvement, and have higher risk. New technology projects are good examples.

The idea of the Enlightened PM is one that knows the right tool to use for the project they have in front of them. While there are some that would disagree, I don’t think agile is the right approach to every project. I still think there’s a place for waterfall. I also know there are projects that will work well using more radical approaches such as Kanban.

One of the discussions revolved around an SAP implementation. Our conclusion was that you could do the initial implementation of SAP using their ASAP methodology (disclosure: I helped SAP develop the project management practices that go with ASAP). However, when you start working on enhancements, you can use agile, or even Kanban to manage those changes.

One of the participants in my class was in the construction industry. While I wouldn’t recommend agile for building a house, it can be used for designing a house.

Occam's Razor

I'm reading the book Plato and a Platypus Walk Into a Bar. As I was reading last night, I came across a reference to Occam's Razor. I liked their interpretation; "Theories should not be any more complex than necessary." Ockham was a 14th century Franciscan Friar and logician, razor refers to shaving away unnecessary assumptions.

I was putting some slides together this week for a workshop I'm conducting next week on Agile. One slide is an overview of Extreme Programming (XP). I'm not going to claim to be an expert on XP, but I have run projects following principles of XP. One of those principles is to use as simple of a design as you can and don't design for features you may not ever develop.

Are you making things more complicated than you need to? I was talking with one of my clients today on keeping things simple...get a basic release of the software completed and in the hands of your users and once they have a chance to use it, they'll have a much better idea of what else they need. Don't try to deliver everything at once. Or as my Dad used to say - KISS - keep it simple stupid!

Are you in debt?

I read an interesting article by a colleague of mine, Scott Francis, on technical debt in BPM projects (read it here). His article got me thinking about technical debt introduced through our project management practices.

Here's an example of what I'm talking about. Let's say you're working on capturing your user stories. You've gathered a group together and had a workshop set up for the afternoon to capture as many stories as possible. Tomorrow you plan on working with your product owner to prioritize the stories. During the afternoon session, someone mentions another user that isn't present that may have some user stories to contribute.

So here's where you decide if you're going to take on some debt. You could delay your prioritization meeting and go talk to this person tomorrow or you could decide to move forward according to your plan. If you move forward, you've just accumulated the debt of having other user stories added somewhere down the road that you will have to deal with.

Now you might be thinking this is agile, change is no problem. But do you know how big that debt is? It might be something insignificant or it might require some major refactoring in order to accommodate the new story.

That's the thing about technical debt. You're making a decision now in order to move things along that will have some consequence later. Do you know how big that consequence is going to be? Just like when you're taking out a mortgage on a new house, you want to make sure you know what you're getting yourself into.

Proof that Agile Works

I came across a very interesting article yesterday from Cutter Consortium (read it here). The article provided evidence about how offshoring doesn't really save you any money, but it also showed how agile does save you money.

The conclusions were based on 20 years of research across 8000 projects. It compared projects of similar size in terms of lines of code. The average project cost $3.5 million. Offshoring it reduced the cost to $3.2 million. The agile project cost $2.2 million.

From a time perspective, the on shore project took 12.6 months, 9.6 for the offshore, and 7.8 months for the agile project.

From a quality perspective, the onshore project had on average 2702 defects, an astounding 7565 defects for the offshore, and only 1372 for the agile project. So even though the offshore project cost less, you made up for it in fixing defects.

This was a pretty comprehensive study and the conclusions are pretty clear. I have been involved with offshore work, and to me that large physical gap between the user and the developer proved very challenging. Organizations I saw struggled to communicate requirements across the gap. I've always been a strong believer in close interaction between developers and users.

Not Waiting for Great

Wired Magazine had an interesting article in the September issue titled The Good Enough Revolution. The article discussed how people are no longer demanding the best, but things that are good, portable, cheap options. Music was one example they used; most people prefer the low quality of MP3s over the higher quality a record can deliver because MP3s are more portable.

This is actually a theme I try to push with my clients. We could spend 9 months building an application with all the bells and whistles or 3 months delivering just the important stuff. It's much cheaper, and if you deliver faster, you realize the benefits sooner. I'll admit I don't have a 100% success rate at getting clients to see my perspective, but I'll keep trying.

Getting people to change

I've been encountering a pretty common situation with some of my clients. While they seem to get what agile is about intellectually, they are still doing things the old way, seemingly unable to break their old (bad) habits.

A colleague of mine, Donna Brighton of the Brighton Leadership Group, introduced me to a new model for change, the ADKAR model, developed by Prosci.

• Awareness
• Desire
• Knowledge
• Ability
• Reinforcement

So the first step is awareness. Are people aware of why they should adapt agile? Are there project failures in the organization? Do projects miss dates, fail to deliver on quality, or run over budget? How can agile solve these problems?

Next, do people have the desire to change? If they've come to accept the status quo, maybe there's no incentive to improve.

The third step is knowledge. This is where training would play a part, so people can understand the desired future state.

However, knowledge doesn't guarantee ability. Can people try the new approach without fear of punishment? Is there support in place to let them succeed?

Finally, when the desired behavior comes about, what is being done to make sure people don't fall back to their old habits?

I have always used the term Organizational Change Management (OCM) when I talk about this type of change, to distinguish it from technical change management such as scope change. I have always approached OCM from the organizational perspective; how do I get the organization to move in the new direction? What I haven't thought about much is that an organization is made of individuals, and each person will make this change journey at their own pace. My effort to change the organization must take individuals into consideration. I'll have my early adopters that can help me. I'll also have those late adopters that I have to account for. I can't assume everyone will change according to my OCM plan.

As for my clients, I think the awareness is there, so it's time to focus on the other steps to get them on the road to agility.

Afraid to Fail

I am reading the book The Art of Possibility and came across an interesting section about failure. There is a story about the composer Stravinsky. When questioned about one particularly difficult section of music, he replied that he didn't expect anyone to play it, but to sound like they were trying to play it. His purpose in writing the passage was to get someone to fail when they attempted it.

Throughout our life, we are told failure is bad. However, it's through failure that we can learn. Thomas Edison didn't think his earlier attempts to invent the light bulb as failures, just steps pointing him in the right direction. Abraham Lincoln had some political setbacks before eventually becoming President of the US.

So when is it ok to fail? If you're trying a new technology, running a pilot project is a good idea. That way, if it does fail, there isn't a lot invested, and you learn something from it. If you're trying to run a 4-hour marathon and come in a few minutes slower, it could be looked at as a failure, but you still accomplished something.

We need to set stretch goals for ourselves. If we don't accomplish these goals, we've still increased our abilities and learned from them. If we always sit in our comfort zone, we never grow.

A stretch goal for me over the past few years has been to develop as a public speaker. I still get nervous anytime I stand in front of a group, but now I am much more composed. There have been presentations I've done in the past that haven't gone as well as I would have liked. I've learned the importance of spending a lot of time practicing before any presentation, even if it's just a project kick-off meeting for a small project team. If I wasn't afraid to fail, I would have never gotten to this point.

So, are you willing to fail?

Photo Credit: Ian Lewis, licensed under Creative Commons

Projects to the Point Conference - Final Wrap-up

I'm home from Cairo. The P2P conference wrapped up on Thursday. I am already looking forward to the 3rd annual conference next year.

The agile track for the conference wrapped up with a panel discussion. In addition to myself, the panel included Jim Cundiff, Jesse Fewell, Dave Prior and Thushara Wijewardena (Dave and Jim pictured here during an earlier session). One of the topics we discussed was when to use agile.

I tend to look at agile as a tool, just like traditional project management tools, ITIL, Six Sigma etc. I think you have to look at your particular project and decide if this is a good project to apply the agile tool. If you're talking software development, chances are that the answer is going to be yes. I pointed out in construction, agile isn't the best approach. If you're building a bridge, you need to have all the requirements before you start construction. However, even here, you could use an agile approach to the design stage.

Dave Prior used the term "enlightened project manager" to describe someone that knows how to apply the right tool at the right time. So do you have all the tools you need in your toolkit?

Day 1 - Project to the Point

I am in Cairo and the first day of the Projects to the Point conference has just wrapped up. Today featured a number of keynote speakers, including the current and immediate past chairs of PMI (Ricardo Vargas and Philip Diab), as well as H.E. Dr Ahmed Darwish, Minister of State of Administrative Development for the Egyptian government.

The Arabian Gulf Chapter of PMI recently conducted a survey into project failure. The leading cause, based on their failure, was project managers without the proper training/experience to run projects. Mr. Diab cited the young workforce in the middle east region as a factor in being able to meet the project management demands.

One of my presentations tomorrow is on knowledge management (KM), very relevant based on today's comments. A part of KM is being able to implement coaching and mentoring to share tacit knowledge among project managers. Tacit knowledge is that stuff that isn't easy to communicate, like how to run a project successfully. It requires more time commitment for experienced project managers as they need to bring their protégées up to speed as a master craftsman trains an apprentice.

Multi-tasking and Kanban

I was at a presentation on Kanban put on by the local agile group tonight. I'm familiar with Kanban, but still picked up some good information.

One thing that struck a chord with me had to do with multi-tasking. In a previous blog post, I've discussed how multi-tasking doesn't work. In tonight's presentation, a statistic was shared that software developers waste 20% of their time when they are multi-tasking.

Kanban is the solution. The idea is you only take 1 task at a time and work until that task is done before you grab another one. You don't have a long backlog of work and you're not trying to manage a full plate of work with all the task switching that goes with it.

I find I'm more successful when I take this approach to work. At the beginning of the day, I figure out the tasks I need to accomplish. While I'm working on a task, I do my best to avoid interruptions. I ignore my email and avoid other distractions (or at least I try). I'll catch back up on email and other stuff when the task is done. It helps when I can keep tasks to an hour or less. If it's a big project, I break it into smaller chunks.

So if you find you are often interrupted, look at how you can break your work into small chunks and turn off the distractions while you complete your task.

Tools & Communications

I had a recent discussion with one of my fellow IT & Telecom SIG board members on a budget item. There was a mis-understanding between us which stemmed from the use of an electronic poll in one of the tools we use to run the SIG. We were using a tool instead of having a conversation, which lead to mis-communications.

I've been working with a couple new clients and the tool topic has come up. My advice is always to get practices down before trying to use any tools to support your practice. One of my clients is using note cards on a white board to manage their stories, and it's working for them. They have a dedicated room for the project, most people are on sight most days, so the technique is working. Inspect and adapt can also mean continue to do things that are working well, don't change just because you can.

As for the SIG, I'm going to change the process for approval of budget items to include a conversation and not just an electronic vote. This will give people the chance to ask questions, clarify assumptions, and make a better decision. It's like user stories - a reminder to have a conversation and not a detailed requirement. Without the conversation, you're going to run into problems.

Keep it Short

This past Sunday, in conjunction with the PMI North America Global Congress, I hosted a Pecha Kucha night on behalf of the IT & Telecom SIG. This served as the launch event for the new PMI Agile Community of Practice.

Pecha Kucha is a style of presentations where you have 20 slides, each lasting only 20 seconds. This was the first time that I, or the other speakers, had given this type of presentation. We all agreed it was fun, but took a lot of work to get right.

I think this brings up an important point. How often have you received a very lengthy email where you couldn't figure out the real message? Like presentations, good writing requires effort. Trying to deliver your message in a short, concise format requires you to really work on refining the message. I think people get lazy with email, throw something together, and expect you to figure it out.

One exercise I like at the start of a project is developing an elevator speech. The idea is to be able to clearly define the purpose of your project in a couple of sentences. The challenge again is to make that message clear & concise at the same time.

So next time you're sending an email, take the extra time to read it through and decide if you are getting your message across in a concise manner. If not, you need to make it shorter.

Making your problems visible

For the past 2 days, I've participated in the PMI Kansas City Chapter's Professional Development Days. On Monday, I gave an overview of Scrum. Yesterday I gave a presentation on User Stories. One thing I mentioned in both presentations; while Scrum won't fix all your problems, it will make them more visible so that you have to deal with them.

After yesterday's presentation, one attendee came up to talk about a problem he was having with his projects. His end users were very slow at providing requirements information. Questions in emails would go unanswered for a week or more. If he got key stakeholders together on a conference call, they would debate among themselves and no decisions would get made. Being geographically dispersed added to the problem.

My advice to him was to capture as much detail as he could but don't hold up the iterations waiting on input. He should build what he could based on the limited input he got and push things to production. An application with limited functionality was better than no application at all, and this would help force the stakeholders to provide additional input.

I find the same advice applies when I'm implementing business processes. If a process is broken, taking any step to quickly apply a fix is better than doing months-long analysis on what the solution might be. Once the quick fix is applied, you can see how effective it is and move forward from there.

It's application of kaizen and lean. Find the biggest issue, take care of it, then go back and see what your next biggest issue is. I told my presentation attendees that they should look at their projects with a product view; they may not get everything right in the first release, so they should plan on going back and updating the application in the future.

More on Servant Leadership

I had an article published in the PMI Community Post last Friday on Servant Leadership. You can read it here. I've had a lot of feedback on the article and wanted to expand on what I said in the article.

Is Servant Leadership the only leadership style that a project manager should follow? The answer is no. Just like any other tool, this leadership style has its place. However, this style of leadership is part of the bigger picture. To be effective as a servant leader requires honesty, openness, willingness to listen, and compassion. Skills required of a servant leader, but of a good leader in general.

A project manager will be called on to perform other tasks that don't fit into the servant-leader model. For example, there may be a conflict on the team that the project manager has to step in to resolve. There's more management specific tasks like assigning resources or managing the budget.

So the project manager has to recognize when they should put on the servant leader hat. Following an agile project management approach leaves plenty of opportunities for acting as servant. The team is self-organizing, so they decide how to complete the work. The product owner is the one that decides on the scope of the project. The role of the project manager is to see that the process is followed and that obstacles are removed.

That's not to say that a project manager has to be following agile to be a servant leader. Really, any leader can follow the servant leader model. They just need to be aware of opportunities where they can serve the team in order to further to goals and vision of the team. In the words of Lao Tzu, "The greatest leader forgets himself and tends to the needs of others."

Keeping Honest with Metrics

Last weekend I purchased the Nike + iPod device. It's a small sensor that fits into my running shoe plus an interface unit that plugs into my iPod. It keeps track of how far I've run, my pace, even calories burned. It's really pretty effective and accurate.

What the tool is really doing for me is keeping me honest. I used to go out and run for 45 minutes or an hour and not worry about the pace. "I'm going around 8:00 minute/mile pace" is what I would tell myself, knowing a lot of times I was really going slower. With my new toy, I know exactly what pace I run. The end result is I am running harder so that I do keep at 8:00 minute pace or better. The proof is here.

This same theory applies to managing business processes. Maybe you know it takes about 5 business days to do end of month processing and get your invoices out the door and your customers take around 30 days to pay the invoices. Is this good? If it used to take you 8 days to do invoices, this is an improvement, but do you really have the metrics to make good decisions? Should you work to improve this process, or is there another process that would be more important to focus on?

However, let's say you knew that by cutting your invoice processing to 4 days and getting your money into the bank sooner, you would earn another $21,000 in interest a month. Now there seems to be more value in capturing detailed metrics on your process and using those to optimize the process.

Like my running, businesses need good metrics in order to run the business effectively. In my case, the results will be in my race times, not increased profits, strong stock price, or increased customer satisfaction.

Simplify, or the problem with Six Sigma

I was on a conference call last night with the other members of the PMI Agile Community's steering committee. Last week we had a successful launch event at Agile 2009 in Chicago and we were discussing how we continue to move forward.

We were discussing vision and values and principles and finally one of the members called "in the grass" meaning our discussion was getting to detailed. As another member stated, we should be focusing on short term plans, not some long term vision when it's hard to figure out what any of us will be doing a year from now.

At this point, I recall a conversation I had with David Allen, author of Getting Things Done. He said we tend to want to focus on where we feel the pain. If our boat just hit the rocks, we don't think about our ship's vision, we figure out how to fix the hole.

To me, this is one of the challenges with Six Sigma. Taking a traditional DMAIC approach takes some time, 6 months is not uncommon for a DMAIC project. There's a lot of analysis that happens before any changes are made. I prefer a Lean approach. Go in, make a quick assessment, improve on the process, and then take another quick look at where to go next. I've implemented new business processes in as little as 3 months with only 1-2 weeks focused on analysis.

With my Agile Community it's even simpler since we don't have any processes in place yet. We need to try some stuff out and see what works. That's not to say a vision isn't important, it helps us make the right decisions. However, now that we're getting members, we need to think about what we have to offer them so they find value in our group. A year from now we can conduct our retrospective, figure out what works and what doesn't, and adjust our vision then.

How are you motivating people

I just finished watching a presentation on Ted by Daniel Pink on motivation in the workplace. He sited a study that found that for anything other than simple mechanical tasks, the higher the reward, the poorer performance got.

He mentioned three things to motivate people effectively; autonomy, master, and purpose.

• Autonomy is the desire in people to have control over our own lives
• Mastery is the desire to continue to improve on a skill or set of skills
• Purpose is feeling like your part of something important, something bigger than yourself

As I listened to this, I realized he was describing the team structure in agile project management. The team is self-directed, deciding among themselves how they are going to accomplish the work as opposed to being assigned tasks from a command & control project manager. Along with this, they are self-motivated and empowered to learn and improve their skills. Finally, any good project starts with a vision, defining the purpose for their work.

When I'm giving presentations, I talk a lot about how you can improve productivity by following an agile process. I often refer to a study done by the Standish group about how many software features are never used (45%) and that by not building features that aren't used through a prioritized backlog, you increase productivity.

This study provides another reason why agile works; the agile team is motivated the right way to perform rather than provided incentives that have the opposite effect. So next time you're trying to get your team engaged, think about this. Are you going to throw money at them or provide the intrinsic motivators that will really get them to perform?

Kanban for process improvement

Kanban is a popular topic these days in the agile world, even spurring some debate about whether or not it is a lean technique. While is does move away from some of the standard elements of agile such as fixed length iterations, in my opinion this is another good tool for any project manager's toolbox. If you're looking for a good overview of Kanban for software development, go here.

As I was thinking about it, I could see how Kanban would be especially effective in Business Process Improvement (BPI) where Lean is being used. The idea to BPI is to apply Kaizen; find an improvement, implement it, watch the results, and then figure out the next improvement and repeat the cycle.

Kanban would work well because you aren't trying to build up a long queue of improvements. The completion of one improvement is the signal to examine your process and identify your next improvement; just like running low on a part in manufacturing is the signal to get more parts.

For example, you've implemented a new business process in your organization, most likely with a BPM tool. A good BPM tool will capture metrics on project execution; how long are various steps taking, are there bottlenecks, are exception paths being followed a lot etc. Based on this, you would identify the next improvement. Maybe, for example, putting in some business rules to automate an approval that is currently a manual step. This improvement would go through your development cycle and be implemented. At this point, your queue is empty; signaling for the next improvement. Or it could be you already have a list of improvements, you just need to pick the next one off the list and move it to the first queue in your development process, which may be elaboration. When it moves on to the next queue (development maybe), something else moves into the elaboration queue. With Kanban, you've turned your development lifecycle into more of a pipeline and your process keeps improving.

The need for agile

So I have a client that is primarily a waterfall shop (at least in the team I'm working with). I was actually surprised because this isn't some low-tech organization but a Silicon Valley tech company; I was expecting agile to be part of their project methodology but they pretty much follow waterfall.

When I started digging into how they run projects, I came across some interesting information. They spend a fair amount of time up front gathering requirements, so I was thinking if requirements are stable, maybe this is ok. But when I asked about changes, they indicated they do have a fair amount of changes once the business owner sees what is being developed. Add to this projects that are taking longer than they want and a lot of time testing and fixing bugs after coding is done.

If this isn't a classic need for agile! They said that they had tried agile before but it hadn't really worked. However, as I talked about some of the benefits of agile, they seemed willing to try. So now I'm working on setting up a pilot project to test an agile approach.

There are a number of reasons an agile implementation can go wrong. It needs executive support, the team needs the proper training, project managers need to accept their new role. We'll see how things go here, but I'm optimistic. Having been in consulting for some time, I can usually sense if my recommendations are going to be implemented or if things will go back to status quo after I leave.

If a tree falls in the woods...

I came across the Copenhagen Interpretation in a book I'm reading. This idea came about in quantum mechanics by Niels Bohr, Werner Heisenberg and others, working in Copenhagen in the early 20th century. In simple terms, the Copenhagen Interpretation says that something doesn't exist until we observe it. So if a tree falls in the woods and no one is there to hear it, it doesn't make a sound.

So what are we trying to observe on our projects? What do we try to capture by our reports, metrics, SLAs etc? The Copenhagen Interpretation supports the idea that we get what we are looking for.

I was doing work at a call center one time. There, they were looking at what percent of time the representatives were available to take calls and when they were "logged out" meaning they were taking a break, doing documentation from a previous call etc. This data point was pretty consistent across the representatives. However, when they dug a little deeper, they found a small set of people that answered significantly fewer calls. This didn't make sense since their availability was the same as others.

As it turns out, some representatives figured out how to scam the system. They watched the representatives around them getting calls and could predict when they would get a call. They logged out for a few seconds, the call went to the next representative over, and they logged back as available, knowing they wouldn't get another call sent to them for a while.

So you're going to get the behavior you look for and reward. If you reward the number of bugs the coders find, they'll find a lot of bugs. If you recognize the person that can fix the crisis, you'll get a lot of fires that need to be fought. So don't think lightly about what you measure.

Anti-Patterns in Project Management

I'm on a project now working with a client on best practices for BPM projects. My focus is on the project management aspect and I have a couple co-workers focused on the software development aspects. One of the topics that came up this week was anti-patterns.

Anti-patterns can be thought of as repeating a set of actions that are anything but a best practice, or, just repeating a bad habit. It's a pretty common theme in software development. Spaghetti code is a good example, continuing to produce code that is poorly structured, confusing, or hard to follow.

But as I was thinking about it, I realized anti-patterns can apply to project management as well. I was in one organization that practiced the "death march" anti-pattern. Projects would get going, everyone would know it was going to be a disaster except senior management, and then the meltdown would happen. Then everyone gets assigned to the next project.

Another of my favorites is management by fire fighting. It's only the fires that get attention and the fire fighter working the long hours saving the day is recognized as the hero. If the organization was a little better at addressing risk, it might have a few less fires (not to mention stop rewarding people for putting the fires out if they could have prevented them in the first place).

So what anti-patterns are in your organization? Can you do something to replace them with some best practices? Are you so caught up in the day to day execution of your projects that you don't see them?

The Five S's of Lean

One of the principles of Lean is known as the 5 S's. Developed in Japan, they are 5 steps that are taken to help become a more lean organization, all starting with the letter S. In English, they have been translated as Sorting, Setting in Order, Shining, Standardizing, and Sustaining. Though the concepts focus on manufacturing, they can also be applied to knowledge workers.

Sorting - What does your desk look like? Do you have piles of papers or magazines you hope to get to some day? Lots of extra cables hanging around? Business cards waiting to be put into your contact management system. The first step in becoming a lean knowledge worker is to sort your desk and office area. Keep only what you are going to need on a regular basis close by.

Setting in Order - Similar to sorting, but with more of a focus on your process flow. It's answering the question of where is the best way to arrange what I need on my desk? When I sort, my computer is something that is on my desk; when I set in order, I set up my laptop just to the left of center, with a second monitor in the center of my desk. I have a space to the right of my mousepad for documents I am working on. Setting in order becomes more important when I'm working on a client site. I have to set up every morning and need to adjust based on how much space I have. If I'm in a conference room with other people, my space may be very limited.

Shining - At the end of each day, taking a few moments to make sure your workspace is clean. Throw away that candy wrapper that's behind your monitor, sort any papers you are done with, and put books back on the shelf.

Standardize - It's important to set up standards with the people you are working with. Do you have an in-box you want anyone from your team to put papers into? Do you have a standard time for your daily stand-up meeting?
Sustain - Keeping the practice going and revisiting the other four S's when you need to. If you get a new, larger monitor, you will have to sort and straighten. If a new member joins the team, how does that change your standards within the group. Sustain is kind of like kaizen, you don't go through an improvement and stop; you keep looking for improvements.

How much technology do you need?

In an interesting twist, today's stage of the Tour de France was run without race radios (article). Normally the radios are used for the team directory to communicate to the riders; things like when the next climb is, potential hazards, or where a rival is in the race. It can become important if a small group of riders break away ahead of the pack; knowing if any of those riders can take over the lead of the race and therefore need to be chased down. So it provides additional information to the riders to help decide on tactics.

The question is how do the radios impact the race? Riders seem to prefer the radios, knowing exactly what's going on. The organizers that put the radio ban in place for today thought it might add some drama. Looking at today's results, I don't think it had a big impact either way.

This got me thinking about tools to help run projects. In the workshop I ran this past weekend, I took a very manual approach; using note cards etc. I mentioned some of the tools that are available, but also said I prefer the manual approach whenever possible. If you have a team co-located, you can get away with posting your user stories as note cards on the wall and writing your burn-down chart on a white board. Things get more complicated when teams are spread across multiple locations. That's when you need to start looking into tools.

So if you're spending a lot of time keeping your tools up to date, you have to think about what value it brings. If the answer is not much, then maybe you should try going without, like the riders did today in France.

The Road to Agility Workshop

Yesterday, with the help of Ron Montgomery, I co-ran a workshop on agile project management. This was a 1 day introduction to agile that was run in conjunction with the Kansas City PMI chapter. If you attended the class and are looking for the slides, click here.

The workshop went pretty well. It was tough getting everything that we wanted to cover included in a 1 day format. We received some feedback about running additional workshops that go into more detail on some topics.

What attendees seemed most interested in was how to sell agile in their organizations. What do you have to do to convince executives this is the way to go?

I think the highlight of the class was when we did a planning poker exercise. We had 50 attendees that we broke into 8 teams. Each team selected their PM and Product Owner. The remainder of the team were the "developers." After creating their user stories, each team went through the estimating process. There were some interesting discussions that followed as they tried to estimate the stories.

Proof of Concept

I have a project going on now that's a proof of concept; working with a client to demonstrate how my company's software can solve their business needs.

Obviously, there are some shortcuts that I can take on this project. For one, I don't have to worry as much about testing because the application is not going to go to production. However, in good agile technique, we are testing during each iteration. At the end, we want to demonstrate a system that works, even though we may not go through all the corner cases we might in a thorough testing approach.

We also don't have to worry about documentation. We'll show the end users how to use the tool, but we don't have to worry about future users. We also don't have to worry about support documentation.

We also didn't do as much up-front work. Typically, because it is a process improvement project, we'll look at the as-is process and figure out the ideal to-be process to implement, then start development based on improvements we've uncovered. In this case, we are just re-implementing the as-is process with the only improvements being what comes with our software; things like improved efficiency, better reporting, better tracking of resources and workloads among other things.

So a proof of concept should be just a first step. Assuming we are successful, we will be able to come in and really help our client. So while the demands on this project aren't as big as a full blown implementation, we still need to show business value. On any project, that's really what it comes down to.

Drinking from a fire hydrant

So I started a new project this week and am in the middle of figuring everything out. I am reminded of when I was starting nuclear power school with the Navy and was told the training was like drinking from a fire hydrant, a lot would be coming out and it was my job to catch as much as I could.

I’m working with a company in financial services, so it isn’t completely alien, but I am finding there is a lot of terminology I am trying to pick up. Add to that the aspect of meeting new people, learning their roles, and how the organization functions. Then there’s the specific aspects of the process that is the subject of the process improvement/BPM project. There are a lot of moving parts.

So how does someone jump into a project and “hit the ground running?” There are a couple of things I’ve learned along the way. The first thing is to get your hands on any documentation and read it. I find that I read everything once, and then go back a couple days later after I have a bit more context and read it again.

Next, ask questions. With a little bit of context, you can ask questions that make it sound like you aren’t completely clueless. I’m usually quiet for the first day or two as I gather that context so I can ask better questions. The questions you ask say a lot about you, or as a t-shirt my daughter has says, “There are no stupid questions, just a lot of inquisitive idiots.”

Finally, you need to relate what you’re doing to what you’ve done before. During some of my conversations with my client in the last day I was able to do this. I could relate some specific requirements they have to what I’ve delivered in past projects. This is when, as a consultant, you show that your experience is worth the money they are paying you to be there.

Sunk Costs

Are you a good decision maker? Do you consider the facts? Explore the options? Look at the big picture are well as the details?

How do sunk costs play into your decisions. If you've invested a lot of time and money into a project, does that influence your decision on whether or not you should kill the project?

Sunk costs is what has already gone into a project that you can't recover. At one telecommunications company I worked for, sunk cost played into decisions. They didn't want to kill a project that they've already spent so much on.

Sunk costs should not influence your decision. You need to look at the current situation and decide if the investment from today forward will result in the benefits you are aiming for. It doesn't matter if you've already dropped $2 million on a project, what matters is what it will take to complete the project and what your benefits will be. What this can mean is that if you are behind on schedule, over budget, and it's going to take a lot more to finish the project, then maybe you need to kill it even if you already spent a bunch of money.

Disconnecting

If you've been following my blog, you'll notice I haven't made a post in over a week. I just got back from a week cruise to Alaska. During the cruise, I was completely cut off from the rest of the world. I wasn't looking at the paper, wasn't checking email, or even using my Blackberry. Now that I'm back, I realize the world didn't stop without me.

It was good to get away, not only from work but really from everything including volunteer work, writing, chores around the house etc. The only regular activity I kept up was working out. Instead, I was taking a lot of pictures, getting to know Aperture better, and enjoying nice meals with my family. Now I feel re-charged and ready to get back into the projects I have going on.

Making Lessons Learned Work

I had a project go live this week, always a good thing. I mentioned that we ran our retrospective last week. Today I came full circle with that discussion. I pulled together the other PMs in the company for an internal discussion of the results of the retrospective.

We did find one common theme that extended to other projects we've executed. And while we discussed how to address the issue, that isn't the point here (but maybe for a future blog post). Today I wanted to discuss knowledge management.

Knowledge management is about changing behavior. If I conduct a lessons learned session and in the future review those notes as I'm preparing for a future project, that's a step in the right direction. It beats putting the notes in a shared drive and never looking at them again. If I pull together my community to discuss the outcomes, that's even better.

So what have you learned lately and who have you shared it with? Do you have an internal team to share with? Would it be a good blog post? Maybe an article for a magazine. Don't just keep it to yourself.

Scrum and the Dalai Lama

I believe truth will ultimately prevail. No system can subdue truth forever.

- The Dalai Lama

Scrum is all about truth. In waterfall, you can hide behind project estimates and big requirement documents, but not with Scrum. I've heard a number of experts say that Scrum will make your problems visible.

One tactic that I've heard with bidding for a project is to bid low and then make up for it with changes. Is that being truthful? Maybe it's the only way to get business.

I do a lot of project estimates, and I always tell people I can give an accurate estimate on the last day of the project. The further we are from that day, the less accurate my estimate is. I don't try to pretend I can finish in a certain amount of time when I know it can't be done. I've moved toward this approach as I've become more agile. I think agile is about getting away from a system that hides the truth.

PM Network

I was quoted a couple of times in the recent issue of PMI's PM Network magazine, talking about portfolio management. You can find the article on p. 46 here.

I like to use Stephen Covey's analogy when I talk about portfolio management. Having good project management in place is like climbing the ladder effectively. Having a good portfolio management process is making sure the ladder is leaning against the right wall.

I still see organizations that struggle with balancing the portfolio. Selecting the right projects to execute can be challenging. This involves having some good selection criteria, which should tie to the organization's strategy.

I had a client that changed selection criteria in the past year. The change in the economy caused them to change organizational strategy and they re-evaluated the projects that were important to them. On the flip side, I've seen organizations that aren't sure which projects should be implemented. Sometimes it comes down to the sponsor that makes the most noise gets their way. With resources tight, this isn't the way to manage a portfolio.

Today's Lesson Learned

I am wrapping up a project this week, and yesterday I brought the team together for our retrospective. One topic that came up was also brought up at my presentation at the PMI EMEA Congress in Amsterdam last week. The topic was how agile teams fit into a non-agile environment.

On this project, I brought my team in with me, agile and ready to go. My client said they were starting to use agile, but it wasn't widely adapted yet. The problem we had was at the intersection between our team and non-agile teams that were doing some of the development work for our project.

Since these other tasks were not complicated, I didn't take into account how long they could take. I also didn't account for the fact that these other resources were not dedicated to my project and had conflicting priorities. You can probably guess the results, we were held up waiting for delivery from these other teams.

So what do you do in this situation? In the future, I will be more actively engaged with these teams and not depend other group's managers to oversee delivery of their components. I'll make sure timelines are understood and deadlines are set. I know I need to engage these other groups sooner in the project and understand what their delivery approach is so I can follow any procedure I need to in order to meet my schedule. In addition, I'll think about contingencies in case there are delays with other groups.

Agile & non-agile can work together, but don't forget that everyone may not be moving at the same speed or the focus your team has on the project may not be the same as other groups that are supporting multiple projects.

How not to run a merger

A merger is a unique kind of project. You’re taking two different companies and jamming them together. There’s a blend of technology and culture that have to be understood in order to be successful. Back when I was at Sprint, I was involved in a number of mergers, some involving as many as half a million customers, so I’ve got some experience here. As a Delta frequent flier (I’ve been Platinum Elite for a number of years), I am observing and feeling the pain of their merger with Northwest.

A merger is in a large part an exercise in organizational change management. You are fusing two different cultures. A lot of people are going to be scared, resistant, or just unsure about the future. The first step in addressing this is vision. What is the future organization going to be? Is it an even blend of the 2 organizations? Is one organization going to dominate? In projects I’ve been involved with, I have been on the side of the dominating organization, assimilating the culture of the other company involved in the merger. Resistance is futile.

Delta is the “Borg” in their merger. In Kansas City, the NW operations were shoved into the Delta terminal. If you’re on a NW flight, it’s almost as if you’re an afterthought. I had to check in with an agent today and after being in the first class line, I was told I had to talk to a “NW” agent at the next counter over, even though it all looks like Delta. If Delta is going to assimilate NW operations, they have to make it seamless to customers.

Another key to a successful merger is understanding stakeholders. There are customers, employees, and suppliers to think about. Each group has separate needs that have to be thought through.

For example, I’ve noticed a decline in moral among the folks working at the check-in counters. I don’t know if they are from the Delta side or the NW side, but they don’t seem to be happy to serve customers. My guess is that these stakeholders have some need that the organization isn’t addressing.

Tied to stakeholder analysis is communications. What are you telling each of these groups? Are you making it easy for customers to understand what is happening? Do employees have the right answers for customers? Is there an effective channel for these stakeholders to provide feedback?

I’ve sent a couple emails to Delta with specific observations of problems brought on by the merger. I’ve received a canned response, so I don’t know if someone is actually addressing some of the issues I have brought up or just trying to pacify me by giving me a few extra miles in my frequent flyer account.

Obviously technology is a critical piece as well. Customer databases have to be combined. Systems have to be tied together. With the state of technology what it is today, with tools such as BPMS, this problem is not as challenging as it was a few years ago.

I won’t pretend all my merger projects went flawlessly. There were technical issues. There were times when people where spending some long hours fixing problems. But in the end, I think both the employees and customers came out better in the end without to much pain. From my perspective, Delta needs to be paying a little more attention to their customers and employees.

Final thoughts on PMI EMEA

I didn't get to see much on the last day of the PMI Congress in Amsterdam, I had a flight to catch.

I did see Bas de Baar talk about social media. His presentation was one of the best I caught. Social media as he described it is about conversations. We seek out groups or affiliations to have these conversations with, such as the #pmot group on Twitter. We make assumptions about people in our group based on their membership in the group, which can be the basis for conversation.

One interesting statistic he provided, about 1% of people are making the content in social media, another 9% comment on what's out there, and the other 90% are just passive readers. This statistic is in line with participation in professional organizations. I have heard the statistic that it's about 5% that are active contributors.

So to get going on social media takes 3 steps. The first step is personal. You have to overcome your fear about using social media and just start using the tools. From here you move to the stage of professional use. This is where you begin to build your reputation. Finally, as a project manager you can start using social media to help in your project (my article on use of twitter for project managers can be found here).

Social media is here to stay. The specific tools like Twitter may be replaced with other things, but the general concepts will stick around, so if you haven't jumped in, it's time to start.

Based on some of my conversations, I think the general consensus of the congress was that there were some good presentations but more that were aimed at a basic level of project manager. The networking opportunities were good. The rumour was that next year is going to be in Milan.

PMI EMEA Congress, Day 2

This morning I attended a session on stakeholder management by Kik Piney. He used a metaphor of Newton's laws of physics to compare with stakeholder management. One interesting idea of his was that of inertia. He suggested having an inertia field on the communications plan to indicate how resistant someone will be to change, as some stakeholders may be much more resistant than others. The force then to get them change will have to be greater.

Kik also talked about the understanding the reasons people might be resistant to change. Some people resist because they just don't know what's going on. Others might not like what's going on. Some may not like the way a change is happening or are resistant because they're not part of the change, just an outsider being impacted by it. Knowing why someone is resistant will help formulate the correct strategy to overcome that resistance.

Jesse Fewell, Dave Prior, Juliet Andrew, myself, and Mattias Petren

Also today, I lead a panel discussion on the challenges of implementing agile. We had some prepared questions as well as questions from the audience. One question that always seems to come up is can you do agile with a fixed price contract?

The answer is yes. I explained my approach of working on fixed schedule and delivering as much of the scope as I can in that time. The customer prioritizes what the team works on. At the end of the fixed time the customer can decide if they want to pay for more work or roll out the project as is. I've had the decision go both ways. The key to the approach is getting the customer to understand you aren't promising a specific amount of scope. You have to build trust with the customer, which comes once you start delivering value.

PMI EMEA Congress, Day 1

The PMI Congress kicked off here in Amsterdam today. The morning started with a set of 4 pecha-kucha presentations on agile. After the 4 presentations, each speaker led a breakout session in a different room. Based on the questions in my room, there are a lot of people new to agile but very interested in learning how it works.

The keynote presentation was by Anne Larilahti from Nokia Siemens. Her topic was sustainibility. It wasn't one of those presentations that gets you all fired up. By her own admisison, it can even be a bit of a depressing topic. However, it did get you to think.

I attended a couple more sessions on agile in the afternoon, including one from a friend I met back at the Edinburgh conference, Sonja Koppensteiner (co-presented with Nathalie Udo). They focused on the planning aspect of an agile project and even had the attendees break up into small groups for an exercise of planning an iteration based on a prioritized backlog. In my group there was some questions about the roles in agile projects; what does the product owner or project manager do?

During the networking reception I had a conversation with Bruce Rodrigues, who is on the PMI Board of Directors. He was asking some of the same questions about agile; is it just the latest trend, how does it really work etc. My observation is that it has been around for a while, but mostly in software. Now it's starting to catch on in other areas.

Another Gold Rush

I've noticed a curious trend recently that reminded me about how history repeats itself. Back in the late 1990s the comparison was made between companies like Cisco and the the companies in the 1800s that made money selling equipment for people looking for gold. Not a lot of people became rich looking for gold, but look what it did for Levi Strauss.

Today it seems the big thing is using social media. There are a lot of people selling this. For example, take a look at this blog post by Shawn Kinkade where he's promoting other blogs that talk about running small businesses (and using social media). Shawn and I worked together at Sprint years ago and now he runs his own business coaching small businesses. He runs a workshop on social media.

Another example, the personal branding blog by Dan Schawbel. This is all about how to use social media to create the brand called you. Dan recently released a new book on branding called Me 2.0.

So what does this mean to the rest of us? It's hard to see how having a strong brand image outside of work will help us in the day to day running of a project inside a company. However, if you build a strong brand by blogging, building a following on Twitter, or actively participating in professional groups like PMI, you can create a reputation within your company as a thought leader. This increase in your expert power will increase your ability to influence, something that will help all project managers.

So if you've been sitting on the sidelines watching the show go by, it's time to jump in. If you say you don't have the time, I say you can't afford not to take the time. Just over a year ago I found myself looking for a new job and because I had already been working on my brand, my search was pretty short. Unlike the goldrush, it won't only be the people selling social media that are going to benefit from it.

The Ultimate Go Live

Image Credit: NASA/Fletcher Hildreth

I briefly turned on NASA TV this afternoon as the space shuttle approached its launch time. It was interesting to listen to the step by step approach to the launch. I can only imagine the time that went into planning the mission.

One of my customers is getting ready to launch the process we've been working on over the past couple of months. I have a standard checklist to help prepare for the go-live. In addition, there will be more detailed plans for the evening that the application is pushed to production.

Some clients I've worked with don't give much thought into deploying applications. They put them in production and if they have problems, they figure out what needs to be fixed. This is a little to casual of an approach for me.

A number of years ago I was involved in some very large, mission critical system deployments. We defined criteria in advance that would be used to make a Go/No Go call if everything didn't follow the plan exactly. If this system doesn't work, we'll try to fix it but if that other system doesn't work we will back out the release and go back to the previous version until we figure out the problem.

When I was in Florida in April, I saw a shuttle launch because of one of these delays. The launch should have been a few days before I arrived, but it was delayed until the day I got there. I'm sure there were a lot of people upset by the delay, but I was happy to be able to see the launch.

How careful are you with launches? Do you have every minute planned out or do you wing it and hope things work out?

Plane Crashes and Culture

I'm reading the book Outliers by Malcolm Gladwell. He is also the author of The Tipping Point and Blink. All of them are worth reading if you haven't read them yet.

This book looks at some of the factors into being successful. For example, a significant number of professional hockey players were born in the earlier part of the year. You'll have to read the book to know why.

At one point he starts talking about plane crashes. In particular, he talks about Korean Airlines in the '80's and 90's. Their flight record was so bad back then the US Army didn't allow military personnel stationed in Korea to fly the airlines.

What was the cause of these crashes? Gladwell talks about how culture is significant. A researcher named Geert Hofstede came up with a term called Power Distance Index (PDI).

Power Distance Index (PDI) that is the extent to which the less powerful members of organizations and institutions (like the family) accept and expect that power is distributed unequally. This represents inequality (more versus less), but defined from below, not from above. It suggests that a society's level of inequality is endorsed by the followers as much as by the leaders. Power and inequality, of course, are extremely fundamental facts of any society and anybody with some international experience will be aware that 'all societies are unequal, but some are more unequal than others'.

The US has a low PDI, Korea has a high PDI. So in Korean culture, it is less common for a subordinate to directly confront their superior. In the case of Korean Airlines, plane crashes can be attributed to the captain making a mistake and the first officer or flight engineer not directly confronting the captain, leading to the crash. Granted, there are always exceptions. The crash of the Air Florida flight in Washington DC in 1982 can in part be attribute to this same reluctance of a subordinate to directly confront a superior, even though both members of the flight crew were Americans.

So what does this have to do with project management? In a leadership position, we need to understand how comfortable our team is in dealing with us directly. It's tricky enough if we're on a team of others from the mid-west US, but it gets even more complicated as we're dealing with multi-cultural teams. We can't expect people to change, especially over the short period of time of a project, so we need to understand our team.

As for Korean Air, they did change their culture. This was done in part by making English the official language of flight crews. This change in language, along with other training, enabled the crews to be more direct with their captains, significantly improving their safety record.

Winning Friends

I'm listening to the audio book of Dale Carnegie's How to Win Friends and Influence People. This is an old book, written in 1937, but the advice is still good. In the book he talks about the six ways to get people to like you;

1. Become interested in other people - Don't focus on yourself, take the time to get to know other people.
2. Smile (sincerely) - that's pretty simple.
   
3. Remember people's names and use them. I always feel special when I'm on the airplane and the flight attendant uses my name when asking what I want to drink.
   
4. Listen - Remember that we have 2 ears and 1 mouth for a reason.
5. Talk in terms of other people's interests - If you're wanting something from someone else, first think about how you can help them. It could be as simple as asking about their children, dog, or prized geraniums.
   
6. Make other people feel important - The key here, and a point emphasized throughout the book is that you need to be sincere in everything you do. If you are just using these ideas as tricks to get what you want, people will see through you.

In this day of high speed, globally networked, virtually connected relationships there are some basic ideas that are still important. Keeping these ideas in mind and taking the time to practice them will result in developing real relationships with people and not just a network.

The Wisdom of Deming

I came across a list of Deming's 14 points and couldn't help but notice the similarity with some of the principles of agile project management. Here are some examples;

• Don't depending on inspection to find defects, build quality in. A good agile project will include testing in each iteration and not let any defects escape the iteration. Using test driven development is a good way to build the quality in.
• Work continually to improve the system. As an example of how this works, I conduct a retrospective at the end of each iteration to see how we can improve for the next iteration. There has to be more than just collecting "lessons learned" at the end of the project to be put on a shelf and forgotten.
  
• Break down barriers between departments. There should be daily interactions between the users and the developers. The development team should include all aspects of the development process including design, build & test.
  

Of course not everything has a direct correlation because Deming was more focused on the manufacturing arena. One of his key themes was the problems were the fault of the system, not people. Management was responsible for the system. It was up to them to fix the problems so people could be successful.

Conversations

I've started reading Mike Cohn's book User Stories Applied and even though I'm not very far into it, I've already found one main concept about user stories that I hadn't fully appreciated, the idea of the conversation.

Mike references Ron Jefferies idea of user stories being the "card, conversation, and confirmation" meaning the information you write down, the conversation that surrounds it, and the test cases you use to confirm the story has been delivered.

The idea here is that what is written down is supposed to be kept simple and it's the conversation with the user that's important. Unlike more traditional requirements approaches, the idea is not to capture everything in writing.

I've followed the approach of keeping away from details when I do user stories, but I didn't fully appreciate why this was important. It's easy to mis-interpret something that is written down. It's easier to have a conversation with a user and understand what they want.

This makes sense in the big picture of agile being about user interactions more than tools or documentation. User stories makes sure we're having those conversations with the users and not trying to create some massive requirements document.

Can you share best practices?

I heard a comment today saying basically that best practices can't be shared, even within a company. They have to be discovered. It got me thinking, can you share best practices?

Templates are good examples. Ideally, these are developed based on best practices. I have heard very strong arguments on both sides of the discussion on whether or not you should use templates.

On one side, by definition, every project is unique and so a template forces you into doing something based on how another project or set up projects were run. Of course with agile, the idea is to not force to much process on the project, which a template can do. It's also putting documentation in front of delivering value.

On the flip side, certain tasks are going to be the same for a lot of projects. For example, justifying the project by means of a business case. Having a standard approach to this step creates a more efficient way of carrying this step out.

The real key is being smart enough to know when a template can help and when it won't. In addition, you should be able to effectively modify a template to meet your project's needs. If your organization forces you to follow steps and use templates, then you have a challenge ahead of you.

So getting back to the first question, can best practices be shared? I think the answer is yes, but...Knowing how someone else does something may give you ideas. Someone else may have solved a problem that you are faced with. The key is to know if their approach is going to work in your environment or just make your problem worse.

Evernote for Personal Organization

I don't normally talk about tools on my blog, but I found one that really works for me. It's called Evernote. It allows me to keep notes, clip web sites, my Twitter feed, or even pictures. Everything can be organized in folders and searched. As I'm adopting the techniques of Getting Things Done, I find Evernote helps with the organization.

What I really like is the sync capability. I can take notes on my work computer and access them through my home computer or my iPod touch. So if I'm at work and think of something to put on my personal to-do list, I can add it and know when I get to my home computer, it will be there. I can also access all my notes from a website if I'm not at any of my computers.

The desktop works on OS-X & Windows. There's iPhone/iPod Touch and Windows Mobile versions. The basic subscription is free, you just have to put up with a tiny ad in the corner. The paid subscription is only $5/month and includes higher encryption, more storage etc.

Clarity

I haven't talked about Morning Coach in a while, but today's podcast was pretty interesting. The topic was clarity, looking at how clear are your future goals & objectives.

This is a pretty common theme for self-improvement. It's like the quote from Alice in Wonderland, if you don't know where you're trying to go, any road will do.

It's easy to lose this long term vision in the day to day chaos of life. Even if we have some idea of where we want to go, we don't always know how to get there.

For me, using a journal is a good exercise. It can get me away from the current chaos for a few minutes and spend a little time thinking about that long range vision of mine. I've also established my goals & objectives for the year, both for work and in my personal life. However, the goals can't be put on a shelf in hope of achieving them. I look them over on a regular basis and figure out what to do each week to help move towards those goals.

In Getting Things Done, David Allen talks about "what's the next action?" What do I have to do today to move towards the goal. Success comes when a clear vision is combined with actionable steps to reach that vision. So what are you doing today to move towards your vision?

Control and Perspective

I'm reading the latest book by David Allen, Making It All Work. This book is a follow-up to his successful Getting Things Done.

One of the themes in the book in control and perspective. Control has to do with how you are executing your tasks and projects. Perspective is focusing on your purpose, vision, goals etc.

I was in a meeting this week with a client and these same themes came up, but in different context. We were discussing program management and how the projects in your program should align with the organization's vision and goals - the perspective component.

During an earlier part of this engagement, I was providing project management mentoring - the control component. Obviously both components are important to success, whether for an individual or an organization.

I think Stephen Covey expressed it well; you could be working hard to climb the ladder (control) only to find it was leaning against the wrong wall (a lack of perspective). Is your ladder on the right wall?

So where do you start? David Allen says "you begin with where you are." If you have a crisis going on with work, you're not going to thing about your vision for the next 5 years, you have to get control of the crisis. You have to "clear the deck" first before you will be able to effectively address the perspective component and think about your vision and long term goals.

Look for more on the book as I make my way through it.

Research on Multi-tasking

I came across an interesting article in Time magazine about multi-tasking. The bottom line is that we truly cannot multi-task, we can just switch from task to task, but at what price? According to the article

When people try to perform two or more related tasks either at the same time or alternating rapidly between them, errors go way up, and it takes far longer--often double the time or more--to get the jobs done than if they were done sequentially.

I know I've been making more effort to stop multi-tasking. One key for me to get something done is to shut off distractions; don't look at email, close out of IM, close the browser, so I can focus on the task at hand.

The article goes on to say a little stimulation can help but to much gets distracting. I like listening to traditional Jazz (no lyrics) when I'm trying to focus. Nothing like some good Coltrane to help get that spreadsheet done.

Another interesting fact, the mind needs quiet time in order to help memories form. Another reason for meditating. On the same line, it's important to get away from all the technology and have some interactions with people.

Everyone's out to teach you something

This idea comes from Don't Sweat the Small Stuff by Richard Carlson.

Imagine everyone is out to teach you something and it's your job to figure out what that something is. By taking this approach, you will become less annoyed with people. So that driver that cut you off is there to teach you to keep alert while on the road. That punk rocker with the pierced lip and eyebrow is there to teach you about not being judgmental. That end user that never seems satisfied is teaching you how to strive for the best product you can produce.

Next time someone has you frustrated or angry or impatient, figure out what they're trying to teach you and you'll find your frustration level go down. You'll start learning the things they're trying to teach you.

Retrospectives

Last week was the end of the first iteration on one of my projects. We had a review with the customer and then the project team held our retrospective. We really focused on 2 things; what did we do well that we want to continue doing and where can we improve for iteration 2.

I first learned about the concept of retrospectives after reading Norman Kerth's book Project Retrospectives: A Handbook for Team Reviews. You can also find more on his site, retrospectives.com.

To often I've been in organizations that pay tribute to the idea of "lessons learned" by holding a meeting after the project, writing some ideas down, and then forgetting about them when the next project starts. I've helped large, global organizations set up lessons learned databases so they can collect these lessons learned from project managers around the globe. None of this is any good without a key ingredient; changing people's behavior. Without that it's just a lesson documented.

I think agile principles really show the value of retrospectives. The retrospective isn't held after the project, it's held often, throughout the project so behavior can be changed immediately. After our meeting last week, we assigned a couple action items and we changed some of our patterns this week. Nothing major, just kaizen at its finest. In 3 weeks, at the end of the next iteration, we'll do it again.

Waterfall is Stupid

So I got to spend one day at the Scrum Gathering in Orlando this week. One of the keynote speakers was Dr Mark Paulk. Among other things, he led the effort to develop the CMM model for software at Carnegie Mellon University.

During his talk, Dr Paulk said "Waterfall is stupid." His point being that the waterfall approach is not an effective way to develop software.

I've had to "observe" the rest of the conference via my friend's twitter feeds and blog posts. Jesse Fewell has a day by day recap on his blog as does Dave Prior.

Space Shuttle Launch

OK, So I got to see the space shuttle launch tonight while I was here in Orlando for the Scrum Gathering. Pretty cool, even though I've seen them before. More amazing is meeting the rock stars of Agile project management that I've been reading about for years.

Where's the fire?

Seth Godin had an interesting blog post called How Far Away is your Emergency. His premise is that we don't address things until they become an emergency, but if we addressed them sooner, they would never become an emergency.

They say the best time to look for a job is when you don't need one. And the best time to invest in a new Purple Cow is when you're still milking the old one.

I had my first race of the season this past weekend, an off road duathlon. I didn't do bad, but it was a tough race. So now I have to think about how to train through March and April, so that when I get to some of the bigger races in the summer, I'm prepared for them. Trying to cram your training into the weeks before the race doesn't work, the emergency is to close.

So easy, a chimp can do it

BBC is running a story about a chimp that showed it knew how to plan for the future. Santino, a chimp in the Stockholm zoo, would gather stockpiles of stones every morning before the zoo opened so that he could later throw them at visitors.

Last night, while at the Kansas City PMI Chapter meeting, my table got into a discussion on the attributes of a PM. One person mentioned a PM is organized. When I added that a PM knows how to plan, they questioned if that was the same thing. I said no, you can be organized in the present but not know what you need to do in the future.

So is planning one of the things that sets a good project manager apart? I've been in organizations that reward the "firefighter" - the person that works really hard to solve a crisis. I've always thought that with better planning, some of these fires might be avoided.

On my current project, we had a risk identification meeting last week. That resulted in some additional plans that will hopefully prevent some issues down the road. So take it from a chimp, a little planning can be a good thing.

The Law of Attraction and Project Management

The Law of Attraction states that we are attracted to that which is of the same nature as our thoughts. As an example, I recently bought a new car, a Mitsubishi Outlander. Before I got the car, I never noticed Mitsubishi's on the road. They aren't the most popular car in the US. Now that I have one, I notice them much more. My thoughts are about them, so I see them more, I attract them.

So how does this apply to project management? Our thoughts can influence how we see our project. If we only think about the negative things, that's what will dominate our project, or at least that's what dominates our observations.

Here's an example of how you can use this to on your project. Most projects involve change. A good technique in change management is identifying and using your early adopters. If you think about being an early adopter, you will attract the early adopters among your stakeholders. You can then tap into them to help move your project forward.

So think positive, it will make a difference.

How do you Test?

I came across this quote from Shigeo Shingo; "Inspection to prevents defects is absolutely required of any process but that inspection to find defects is a waste."

I brought up the quote in a webinar I was giving on Six Sigma last week and it brought some interest from the audience. So how do you test you product?

I've been in many QA roles through my career. Writing test cases, reviewing test results, re-engineering a testing process. The best approach that I've found is to get the end users involved in testing early in the process. The folks that are using the software (or whatever you're building) should write the test cases on how they would like to see it tested, as the requirements are being captured, not after the product is developed. Scott Ambler refers to this as Test Driven Development.

On a related note, Dave Prior has a post talking about being done and being done done. So when is testing done? Is it after development is done, i.e., waterfall? Or is testing integrated into your development process?

Quality should be built into the product, not inspected for after completion.

How Much Process?

So I gave to presentations this week on different topics. Monday I was the presenter at the Kansas City Chapter of PMI. My presentation was on Scrum. Today I talked about 6 Sigma on the PMI IT & Telecom Special Interest Group's monthly webinar.

One of the principles behind Scrum (and really all agile approaches) is to put personal interactions before process. Don't get bogged down in the process, just have enough to keep things moving forward. Six Sigma assumes a more rigid set of processes.

So where's the balance? That of course depends. Today someone asked me if you can apply six sigma if you don't have any well-defined processes. My response was no, you have to get some processes in place first before six sigma could help you.

But you can get to focused on process. Lean talks about eliminating waste. To much process can introduce waste. Do you have to produce specific documentation that doesn't add value? That's what you want to get rid of.

The trick is figuring out what is just enough. Map out your process. Look at all the inputs and outputs. Then decide what isn't adding value to your product. That's what you should get rid of.

Barriers to Innovation

I came across this video that addresses some of the barriers to innovation at NASA.



Do any of these conditions exist at your workplace? People not stepping out of their comfort zone? Silos? A process that inhibits innovation?

I was presenting an overview of Scrum last night at the Kansas City PMI Chapter meeting. One of the things I stressed is the Scrum (and any agile approach) is supposed to be flexible; using Scrum doesn't lock you into specific steps. As the Agile Manifesto states "Individuals and Interactions over Process and Tools" Does your project management process allow you flexibility to be innovative?

Reputation

How often do you think about your reputation? It's something that you may not focus on, but it doesn't take much to ruin it, as Michael Phelps recently found out. Blogger Andy Beal shows how quickly Phelps killed his reputation in this post.

In the Navy we had a saying; "it takes a whole lot of atta boy's to make up for one oh crap!" The idea is that you can work hard to build your reputation but one mistake can screw it up.

As project managers, we don't have direct authority over all the resources we need for a project. We have to rely on influence as a form of leadership to reach our project goals. Without a good reputation, we make our job more difficult.

So how do we build our reputation? Integrity is important. Keep promises. Deliver what you say you will. When you hit an obstacle, be open with your stakeholders. Admit it when you make a mistake.

When you're trying to decide a course of action, think about the impact on your reputation. Cutting corners on testing? Padding your expense report? Having one to many drinks at the company dinner? As Michael Phelps found out, one little slip up can have big ramifications.

Continuous Improvement

I had an article published at the end of last week through PMI's Community Post, read it here. The article is on continuous improvement in project management.

When you cook...cook!

This phrase is a Buddhist directive focusing on being in the present moment and thinking about what you are doing. I like it because I like to cook. When I cook, I really focus on what I'm doing, trying to get all the details just right. It's a way for me to unwind after a long day.

We should have the same level of focus on our projects as well. How often do you find yourself drifting off during a meeting, thinking about some other task, checking your Blackberry or email?

Well, stop it!

If you're in a meeting and not paying attention, either you don't need to be at the meeting, or you should be paying attention but your distracted. So either walk out, or take a deep breath and focus on what's going on in front of you. Put away the Blackberry. Leave the computer at your desk. Be present in the meeting. Maybe you'll hear something you need to know.

Why Your Company Could Be Next

There was a good piece in CIO magazine that you can read here about why a lack of visibility is the biggest risk to all companies.

One of my clients really gets this. They're all about visibility. As we help them develop improved business processes, we are also tying everything together from a reporting standpoint so they can see how everything is doing. Because everything is being built on one platform, it's easy to develop a sophisticated reporting tool to monitor it all. It gives management they need to effectively run the business.

How we learn

Last night at the KC Chapter meeting for PMI, the guest speaker was Cindy Meyer of LeaderQor Associates. Cindy focuses on leadership development and her presentation looked at how we can learn and achieve new goals.

According to Cindy, we learn only 2% from either inspirational or impacting activities. Inspirational would be listening to that great motivational speaker. Impacting is some major event, such as having a heart attack. The rest of our learning comes from spaced repetition. Think about how you memorized your multiplication tables in primary school.

This is consistent with other messages I've heard. One specific statistic is that it takes 21 days of repeated behavior to change a habit or create a new one. There's that repetition again.

Cindy laid out 7 steps for goal achievement:

1. Set up goals that are SMART (specific, measurabe, achievable, relevant, time-bound).
2. Understand the rewards or consequences for either reaching or not reaching the goal.
3. Understand the obstacles in your way.
4. Develop the solution to reach your goal.
5. Detail the action steps for the solution.
6. Assign target dates for the action steps.
7. Delegate tasks as appropriate (obviously this is for business goals, not personal ones).

Nothing surprising or earth shattering here. It's along the lines of Getting Things Done; break down your goals into pieces that can be executed on a day by day basis, the next action.

So what are you waiting for? Have you had that great idea that you never got around to? What can you do today to start working on that goal? It may only be 1 small task, but if you keep at it, you can reach your goal.