I responded to questions on wide variety of topics  from students which included different  PMI certifications, value/demand of such certifications and how to handle seemingly daunting task of filling out PMP certification application.  Judging from the length of session and non-stop questions from audience, I felt that students gained plenty of information they were seeking regarding PMI and PMP certification.

One of the things that people who are planning to take PMP certification exam need to be aware of  is the upcoming changes to exam starting later this year. PMI recently undertook RDS (Role Delineation Study) to ensure that credential reflects contemporary practice and  evolves to meet current needs in the project management profession. As result of the RDS study, PMI is making changes to PMP certification exam starting August 31, 2011.

The changes will impact about 30% of PMP exam. You will notice changes in certain areas of exam. Specifically, questions on Professional and Social Responsibility section (6^th domain) now will be part of every other domain rather than being as separate domain on exam. It seems that PMI now recognizes the importance of Code of Ethics and Professional Conduct as part of day-to-day work for project management professional, hence the reason for the change in PMP examination.

Specifically, he was referring to the problem of padding in estimation for tasks. Being new to software industry, he was not sure whether the estimates provided by his team members were accurate or padded.

The padding refers to extra time added to a schedule that isn’t really needed but that is added just to feel confident in the estimate. The impact of padding could be significant on project schedule. The quality of the estimates directly affects whether or not the project can meet scope, cost and schedule commitments. The accumulation of padding all the tasks can result in overly cautious project schedules and uncertainties across the project schedule.

According to one estimate , the average company completes only 37% of IT projects on time, while only 42% finish on budget. Much of this is attributed to the difficulties in gathering accurate estimates of effort.

The reasons for padding the estimate could be many. The resource might have multiple projects that they work on. They have overlapping work from those projects. They have nonscheduled time or they are given conflicting priorities. Rita Mulchay explained it nicely in her PMP preparation book by summing up team member’s thoughts:

“I have no idea how long it will take. I do not even know what I’m being asked to do. So, what do I say? I will make my best guess and double it! ”

There are a number of approaches project manager could take to address the issue of padding:

• Use expert judgment. Let the experts review the estimates provided by estimators. The experts can identify cases where the estimation doesn’t seem right. These could be senior or principle software engineers within the company.

• Use estimating techniques such as stochastic estimation. Ask team member to provide a range of estimates. For example, asked member to come up with task estimate for best case scenario, worst case scenario and most likely scenario. Using the 90% confidence factor, one can come up with reasonable estimate.

• As project manager, you should provide sufficient time to estimator. If estimator is asked to estimate a task on the spot, estimator may feel pressured and provide a number just to get us off their back. Estimators should be provided enough time and encouraged them to think carefully and thoroughly to come up with estimate.

• To minimize the schedule risks of your project, it’s

• better to apply the padding at the project level instead of at the individual task level. This is commonly referred to as buffer. Make sure to communicate about project level buffers to all the team members to keep everyone on the same page.

• Instead of asking for estimation of task duration asked in terms of task effort. This helps avoid introducing padding into the estimation process. Also, understand that people are human beings and no one works hundred percent of their time. When estimator provides an estimation of the effort, the numbers should reflect continuous, nonstop work.

Over the weekend, I facilitated fabulous workshop on Advanced Microsoft Project sponsored by PMI Silicon Valley chapter. According to instructor, every time software developer is interrupted it takes 14 minutes on average to get back to development work.

Additionally, I have experienced that software quality assurance engineers generally estimate efforts over cautiously whereas software developers tend to provide over-optimistic estimates. Understanding and factoring such elements can help improve accuracy of estimates.

Lastly, for medium to large projects project estimation software such as Cost Xert or KnowledgePlan can be utilized effectively. There are also other methods such as System Development Life Cycle (SDLC) which consist of a set of best practices that lets engineers break projects down into recognizable and repeatable steps, processes, tasks and outcomes, each of which can be accurately estimated.

Hope to finish my blog on Negotiations soon. Stay tuned!

My article on Project Risk Management using Mind Map is accepted and published this week on UC Santa Cruz Project Management web site. This is a great web site discussing various topics on Project Management. People involved in Project Management may find it useful and learn a lot. I encourage you to visit it.

My article is the  focus topic for the week of December 22nd. You can view it at:

http://svprojectmanagement.com

You can also view this article anytime by visiting:

http://svprojectmanagement.com/is-mind-map-useful-for-risk-management

Today, I’m going to talk about the importance of team agreement. To describe the problem, allow me set up the scene where project meeting is taking place.

During planning phase of project, project manager was having an important meeting with stakeholders. The discussion was surrounding the requirements provided by stakeholders. Some of these requirements were in conflicts with each other. Some of the requirements had to be eliminated in order to keep the project in the confines of defined scope.

Various stakeholders felt very strongly to keep their requirements. There were intense arguments made by multiple stakeholders. After about 20 minutes into the meeting, three key stakeholders abruptly got up and walked out of the meeting. Same thing went on for next several meetings.  Needless to say, the requirement analysis phase of the project was finally completed but left behind a team that did not function well together, along with a trail of frustration, bad feelings, and jurisdictional divides.

This is a real-life scenario that occurred on one of the corporate wide IT projects that I participated in as stakeholder some years ago. What went wrong in the situation? What could have helped to avoid the situation? If there were proper team agreements defined and utilized, the situation could have been avoided.

The team agreement is an effective way to address such issues. When you create a set  of team agreements on how you want to function when difficult  issues arise, you are much better equipped to handle the challenges that occur. The team agreements help you work together in a way that truly honors each other and a return to a sense of defined purpose when you experience the inevitable challenges of working in team settings. Each member needs to learn to communicate with professionalism, confidence and compassion even in difficult situations.

The critical part of a successful team environment is making sure everyone has the same vision, before moving into action. The classic “forming, storming, morning, performing ” stages that teams go through are best managed with set of agreements. The agreements serve the norming function as members of the team agree on how they will work with each other. The agreement reflects the resolution of their “storming”.

The team agreements can be utilized on projects using SCRUM as well. You should continue to maintain team agreements and update them as the outcome of retrospectives. The refined team agreements can be used in subsequent sprints. This is an important step in the evolution of ‘just a group of people’ to a SCRUM team.

One of the most important tasks in early meetings is to sign off on a team agreement that clearly defines your expectations for each other, your operating parameters, and the ways in which you will define success at the end of the project. There are numerous ways to create a team agreements.. The main idea is to keep it simple and real. It should be defined by the team, not just by project manager. Ask team 3-5 things they believe a team should do to support themselves moving toward the goal. They might come up with items such as “active participation” and “communication”.

Encourage them to identify specific soft skills and interpersonal behaviors. Make sure to get signoff from the team on agreements document. Some teams agree to this by demonstrating a show of hands, others may physically retain the paper that includes the list of agreements and brainstorming notes. This step enforces public accountability with each other and project manager. Some teams have them even printed up and post them near their offices or conference room.

I have included a sample set of team agreements to use or to help you compose your own.

• Have Open communication and active participation

• Utilize Lessons learned from experience

• Treat all team members with respect and value other team member’s opinion and time

• Be a Leader

• Respect others’ views/thoughts and appreciate contribution

• Resolve all conflicts positively

• Hold yourself accountable

• Define the operating parameters within which to conduct meetings

• All formal meetings have an agenda and have one conversation at a time during the meeting

There are number of benefits of creating team agreements.

The team agreements  help team members  work together in a way that truly honors each other and return to a sense of aligned purpose when team experiences the inevitable challenges of working on any project. It makes everyone in team aware of the expectations of the group.

It creates a foundation for building trusting relationships, which strengthens the team’s infrastructure. It provides forum for open communication. It also allows team members to be accountable and allows project manager to offload this responsibility.

What’s more? Having the team agreements can help your team get rid of assumptions about what’s expected as they interact with each other which can increase trust and impact more of and performance. A highly functioning team is a infrastructure for a successful organization, and as a leader, you can help the team set the foundation for success!  The ultimate role model for the agreement is the team leader. Talk about it, refer to it and most importantly, use it!

Happy Thanksgiving!

breakfast session on Using Mind Maps for Risk Management.  The presentation was good. It would be been better if presenter’s brand new laptop worked to display his slides/Mind Map templates. We ended up spending quite a bit of time out of an hour to fix the problem.  I heard a comment from somebody in back…”talk about risk management…”   Still, I thought the talk was pretty good and found presenter very enthusiastic to  present the topic.   I found it interesting and it made me think about how one can use Mind Map for Risk Management on different projects.

How can we use Mind Map for Risk Management? Let’s first talk about Mind Maps briefly ( look out for my upcoming blog on Mind Map / MindManager).  What is Mind Map? Mind maps are a graphical network diagram with nodes or branches. They are laid out using different colors, and icons to help convey an idea. Mind map can be very useful for brainstorming activity, hence they are often called brainstorm maps, are illustrated views of an idea. One of the most popular commercial  Mind Map tools available is MindManager. We will use it for the purpose of discussion.

According to PMBOK,  Time, Cost and Scope are three components of Triple Constraints. Risk has the potential to affect all of them. It’s critical to manage risk as  part of overall Project Management. That means identifying a set of processes for risk management that includes planning, identification, analysis, response, monitoring and control.

Mind Maps can be especially used for risk identification. The iterative nature of the risk identification process makes it a perfect candidate for mind maps. Not that it is also nonlinear as it is being done continuously during various phases.  One risk may turn into other identified risks. It can be difficult to track them and express relationships between them as risk log evolves. During a brainstorming session, project manager  encourages team members to identify risks and uses a mind map to capture them and generate new ideas from the team. Again, this will be an iterative process and mind map for risk will evolve over the time. Over the time, relationships and dependencies evolve for various risks and are represented using nodes and arrows in mind map.

Later on, this mind map can be utilized for subsequent processes of Risk Management as well and can be extended to include risk response strategies, impact analysis,etc.

In summary, the mind map enables brainstorming, relationship and prioritization of risks  in graphical form (picture is worth 1000 words). It also helps to categorize project risks into the time, scope and resource categories. The mind maps present unique opportunity for project manager to mange risk effectively.