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."