Have a Kit-Kat ;-)

Let’s take a break and enjoy few project management proverbs, humour, whatever you call them… ;-)

 

Nothing is impossible for the person who doesn't have to do it.

 

A user is somebody who tells you what they want the day you give them what they asked for.

 

What you don't know hurts you.

 

The conditions attached to a promise are forgotten, only the promise is remembered.

 

Estimators do it in groups - bottom up and top down.

 

Good estimators aren't modest: if it's huge they say so.

 

Difficult projects are easy, impossible projects are difficult, miracles are a little trickier.

 

If at first you don't succeed, remove all evidence you ever tried.

 

There are no good project managers - only lucky ones.

 

The more you plan the luckier you get.

Getting Started with Project Leadership

By Cornelius Fichtner, PMP

In May of 2011 The Project Management Podcast launched its Project Leadership Series at www.pm-podcast.com. The series started with interviews with Thomas Juli, author of Leadership Principles for Project Success, and Rick Valerga, author of The Cure for the Common Project: Five Core Themes that Transform Project Managers into Leaders. More interviews and discussions on project leadership are planned throughout the year. To kick us off let’s begin with an explanation about what project leadership is and how project managers can start out on the path of becoming true project leaders.

Defining project leadership

“There are so many definitions of leadership out there,” said Thomas. “Leadership has to do with the right attitude and understanding the core principles of building an overall vision, knowing about the power of collaboration, knowing how to promote performance in the team he or she is leading, and then still having the maturity to reflect on their own activities and creating a culture of learning. And last but not least, a leader ensures results because this is the bottom line.”

Rick agrees. “I define leadership as the ability to influence others to deliver results,” he said. “Project leadership exists at the nexus of project management and general leadership.”

Project leadership doesn’t mean being a strategic visionary sitting at the very top of your organization. It’s about leading the project team to achieve their objectives and producing a successful result.

Getting to success

“If you run a project, you have to be knowledgeable and experienced in project management,” said Thomas. “Project management is basically structuring chaos and without the structure, you cannot really be creative. That means without project management, there cannot be project success.”

However, Thomas doesn’t believe that project management skills are the only thing necessary to deliver a successful project.“Leadership gives the project a direction, the right direction,” he said. “If you talk about sufficient conditions of project success, we’re talking about leadership.”

Without someone providing this overall direction, the project team members run the risk of going off in several directions, or nowhere at all. It’s difficult to achieve results in that situation. Thomas believes that to get to success projects need both management and leadership. Fortunately, one person can fill both functions.

Leadership basics

“Integrity is the absolute foundation for project leadership,” said Rick. “Integrity means never letting your project live a lie. So if your project plan is a house of cards, or your schedule will be indisputably delayed, or if you discover that your product will fall flat in the market, you need to have the courage to bring these issues to light.”

Rick said that managing expectations is key to building integrity. “When we’re doing this, we’re making responsible commitments even under duress,” he explained. “That’s integrity.” He also explained that integrity comes from solving the projects’ toughest problems without destroying our team members or their families, and providing frequent up-to-date, consistent messages that are agreed across all the project stakeholders.

Leading others

Teams are at the heart of projects, and project leaders can’t lead if they don’t have people to lead. “Let’s face it, projects are at their best when people are at their best,” said Rick. “I’m not just talking about taking care of the troops and then getting out of the way which many project managers do. Projects are at their best when all the people are at their best including the sponsor, customers, suppliers, adjacent functional organizations.”

Thomas agrees. “As a leader, it is your responsibility to create an environment that promotes performance on both the individual and the team level,” he said. “First of all, you want to be a role model. You have to walk the talk. Demonstrate authentic leadership.” By that, he means making sure that your words and actions align. Don’t set rules for the team and then break them yourself.

“You really want to empower your team,” Thomas added. “That means you have to give the team the information it needs and you have to share the power so that the team can actually get the opportunity to excel and have an active hand in project success.”

When the team feels empowered, there is no need to micromanage them. Thomas believes that it is important to want them to feel empowered, and not just pay lip service to the team. You have to be able to trust the team members. “You have to let it happen,” he said. “You have to give the team the opportunity to show how it can perform. That’s very important.”

Starting out

If becoming a project leader sounds difficult, Rick had some simple advice about how to get started. “One way to start is by simply listening,” he said. “We have a vast amount of knowledge available to us through our stakeholders. We need to make sure that we are regularly tapping into it.”

Another easy step towards becoming a leader is to celebrate performance. “You want to look for behaviors that reflect the purpose and values, skill development and team work and reward, reward, reward those behaviors,” said Thomas. “Don’t wait until the very end of the project to celebrate the same results. Celebrate performance.”

The great thing about leadership is that we’ll instinctively know what it feels like to be doing it right. The people around us will let us know that we’re doing a good job. “In the end,” Rick said, “our projects are judged by people, the customers, the sponsor, the team members. Most of these people are not imbued with project management theory. They only judge whether the project lived up to its billing as interpreted by them. It’s a subjective process and above all, these people hate to be surprised. So the best way to address this is by making expectation management a daily mantra.” That’s good advice for any leader.

Listen to the complete interviews on project leadership with Rick Valerga and Thomas Juli on The Project Management Podcast for free at www.pm-podcast.com.

 

About the author: Cornelius Fichtner, PMP is a noted project management expert. Since 2005 he has interviewed over 100 project managers from around the world on The Project Management Podcast at www.pm-podcast.com. The interviews are available for free. Topics cover all areas of project management like methodologies, PMOs, earned value, project leadership and many more.

Types of Estimating Techniques

In project management, we will be doing estimates for time and cost. There are few techniques that can be used to perform estimating.

Estimate is a quantitative assessment of the likely amount or outcome. It should always include some indication of accuracy (e.g., plus/minus x percent).

Analogous
This is an estimate done using the values of parameters from previous experiences with similar activities.

Parametric
This estimating technique uses statistical relationship between historical data and other variables to calculate an estimate for activity parameters. For example, multiplying the planned work to be performed by the historical cost per unit to obtain an estimated value.

Three-point Estimates
This estimate is known as the PERT (Program Evaluation Review Technique) estimate. This technique uses weighted average of optimistic, pessimistic and most likely estimates.

Reserve Analysis
An analytical technique to determine the essential features and relationships of components in project management plan to establish a reserve for the schedule duration, budget, estimated cost or funds for a project.

Bottom-up
Estimating is done on individual work package of the WBS and rolled-up to get the total estimate for the project. This estimate can be the most accurate because it is done by the subject matter expert themselves. However PM needs to be aware of padding.

Or, we could do it the Dilbert-way :-) :

Tips on Handling a Problem Team Member on your Project

By Margaret Meloni, MBA, PMP – www.pducast.com / www.margaretmeloni.com

Oh there is a problem alright. And it starts with the fact that you have a boss, peer or project team member who is completely in denial about the chaos that is all around them. If they do see any kind of issues, well those issues start with you. This is not meant to be spiteful. This is the behavior of someone who is completely oblivious to the fact that they cause problems. If they do have any inkling that there is an issue, then they have a perfect excuse. Do any of these sound familiar?

• "I did not call you back because you never left me a message."
• "I did not forget our meeting; my admin did not put it on my calendar."
• "My office may look messy, but leave it alone. I have a system and I know where everything is located."

What kinds of chaos surround this person? Their chaos can be lack of organization, time related or memory related. The chaos created by this person looks like chaos created by creative types or even by someone who deceives others into thinking they are organized. The key here is that they absolutely do not own their issue. They really do not see that there is a problem. If they miss a meeting, they can blame their assistant who did not remind them of it. They really think you didn’t leave them a message because their assistant gave it to them and it was buried under the piles of paper on their desk.

So what's a project manager to do? Well let's look at what not to do first - do not blame them. Do not put them on the defensive. Do not constantly harp on them about the problem. Do not argue with them about their excuses, just move on. Find a way to work around the problem because you’re not going to be able to change them.

Now step back and look at the big picture. What do you want from this working relationship? Where do they have problems and how can you help? Even if you don't feel like you want to help them, remember you are helping yourself too! With that in mind:

• Be proactive. If you know their issue will cause a problem for others on the project team, step-in. This may mean you politely remind them of customer appointments or work package due dates. It may mean you hand deliver important memos to them and watch them read those memos. What you are doing (without them knowing it) is nipping a potential problem in the bud.
• Create a simple process for organizing shared information. Stay away from their personal space, but be willing to be responsible for other areas. Enlist the help of others on the project, too. Your problem child may respond to the organization and join in because they want to be part of the group.
• If they work for you as a full-time project resource, be the boss and give them direction. Advise them that missing meetings, deadlines and not returning phone calls is not acceptable. Mentor them away from the damaging behavior and toward a positive outcome.
• Acknowledge that they have other skills. There are other areas where they are strong contributors, which is why they got selected to work on the project in the first place.

You may think that’s a lot of trouble to go to, but it will actually save you time and make your job less aggravating. Hand delivering memos might seem a bit extreme but you’ll know that they’ve been read. Another method that works is to deliver the memo and have them initial that they have read it. This also serves to create a paper trail that no one can argue with.

If you do have to call them on the carpet about their behavior, ask them how you can help them get control of their disorganization. Knowing that you’re willing to help them will make them much more willing to work on the behavior that is causing so much chaos for the project.

As for their other skills, take advantage of them. You may want to find what they are best at and exploit that. If your problem person excels at something that another project team member isn’t so good at, perhaps he or she could take the burden off their co-worker in exchange for that person handling their calendar.

And remember, their behavior is about them, it is not about you. Don't take it personally.

 

About the Author: Margaret Meloni, MBA, PMP, is an executive coaching consultant for IT professionals. She helps project managers and teams work together better by improving their soft skills. Learn how to successfully combine your technical and soft skills in her webinars from The PDU Podcast (www.pducast.com) and from her website at www.margaretmeloni.com.

Getting to Know the Stakeholders

There are many reasons why you should Identify Stakeholder early in the project life cycle. Most important reason is that, your stakeholders can influence the direction of the project. Based on the information that they share with you or the things that they say to other people, your project is impacted by them.

Stakeholders can be anyone who is directly or indirectly involved in the project. They can be:

• The sponsor
• The customer
• Senior management
• Functional departments
• The public
• The project team
• Alice in customer support team
• The sundry shop 100m from your project site

The bigger your project, the more stakeholders are involved. And you need to figure out how to reach out to them and understand what are their needs. As the PM, you need to find out how your project will impact them during and after it is completed. We need to find out what is the extend of influence each of the stakeholder has and how their opinions or decision will impact the course of our project.

To begin with, when identifying a stakeholder, we need to know his role, department, interests, knowledge level, expectation and influence level. Find out as much as you can about each and everyone of your stakeholders. Also, we need to find out what type of information they require, how they like it to be presented as, how much they want or need to know, etc. Some people likes a lengthy, narrative, very detailed reports. Some prefer graphs and bullet points. Some just need a one-liner.

Next, identify the impact or support that you can get from the stakeholders. Each stakeholder will impact your project differently. Some will be supportive, others nonchalant. Some don’t event want to talk about the project. Check for:

• Power/Interest
• Power/Influence
• Influence/Impact
• Salient model – group by power, urgency, and legitimacy

Then, you need to assess their reactions and responds in differing situations. Observe your stakeholders during meeting or discussions or functions. How do they talk to people? How do they respond to questions? What type of questions that can make them open up to you? What type of questions that make them clam up? Are they a risk taker or a safe player? What is their corporate style? How do they negotiate or get things done? Try to learn as much as you can about your stakeholders, not only from other people who knows them, but also through your personal encounter and observations.

Last but not least, communicate with your stakeholders. When you have found out the frequency of reporting that they prefer, make sure you do it as you have agreed. Tell them what they want to know and always ask their opinion on the progress so far. However, be careful not to allow scope creep. The reason you continuously engage your stakeholder is to gauge the health of your project from their perspective. They will take the opportunity to ask you to include extra features or new functionalities, make no mistake. But use your charm and wisdom as a project manager to manage this. Remember, project managers spend most of their time communicating, so communicate effectively and wisely.

Project Scope Monitoring and Controlling

The last two processes for Scope Management, fall under the Monitor and Control process group.

Verify Scope requires the validated deliverables to be checked and verified against the requirements documentation. Why is it “validated” deliverables? It is “validated” because it has gone through the Quality Control process.

The inspection done on the validated deliverables is performed by selected eligible stakeholders. This inspection session is usually called the User Acceptance Test or UAT. It could also be called product reviews, audit or walkthrough.

Quality Control and Verify Scope could be done in parallel. However, it must be known that quality control is about correctness of the deliverable and verify scope is about acceptance of the deliverable.

At the end of this process, we will either have accepted deliverables or rejected deliverables; which means there will be change requests.

Control Scope “is the process of monitoring the status of the project and product scope and managing changes to the scope baseline” [PMBOK Guide 4th Edition].

Equipped with the project management plan, work performance information and requirements documentation, variance analysis will be performed to measure the work performance at specific dates throughout the project life cycle.

Based on the findings, there will be updates to project documents and change requests where applicable. Through the variance analysis, we will know the current health status of the project and subsequently deciding on corrective or preventive actions.

Managing Project Communications

Who are the most important people in your project? Your stakeholders.

These are the people that will determine whether your project will fly or flop. These are the people who will tell you what, when and how they want what they want. They will tell you why they want what they want. Sometimes, they don’t really know what they think they want. Bottom line, these are the people whose needs and wants must be addressed, analysed and fulfilled.

The PMBOK Guide has one knowledge area dedicated specifically for stakeholders. And it has all to do with communicating; Project Communications Management. This is the knowledge area where processes required to ensure information are generated, distributed, stored and later disposed of. This knowledge area also tells us how and why who gets what information when.

Within the process Initiating process group, we will identify the stakeholders. We will be able to categorise our stakeholders and later disseminate information according to priorities.

Planning communication comes next under the Planning process group. During this process, we will answer the question: How and Why Who gets What information When.

In the Executing process group, we will distribute relevant information based on the plan that we have created in the previous process. We will also manage stakeholder expectation; which means we will communicate effectively to meet their needs and addressing any issues that is happening.

Throughout the project lifecycle, we will be reporting the project performance to the stakeholders. This task falls under the Monitoring and Controlling process group. Here information is collected and the project performance is presented in ways of status reports and forecast.

Remember that communication can be in many ways; internal or external, verbal or non-verbal, written or oral, formal or informal, vertical or horizontal, official and non-official. Each project team member must be equipped with the right skills to communicate effectively, within the team or with other stakeholders. When wearing a project manager’s hat, we are not only communicating project progress, we will also be required to do negotiation, conflict resolving, educating, managing expectations, etc.

Didn’t we already come to terms that project manager spends most of her time communicating?  Thus, we better make sure that we do it excellently!

 

[Image googled]

Strengthening the Boundaries with Scope Statement

When you have all the requirements documented, it is time to confirm the boundary of the project. If you remember, in Project Charter, we have a high level listing of the things that will be done in the project, and the things which are out of the scope.

In the Process Group: Define Scope, we will make a more detailed description of the project and the product to be delivered. With the additional information that we have collected during the requirements gathering activities, we are now able to include more information related to risks,quality, assumptions and constraints.

To be able to come out with the project scope statement, we will need the high level information from the Project Charter and detailed requirements from the requirements documentation. We will need to extract the necessary information to come out with the scope statement.

For this process group, PMI identifies four tools and techniques that could be used to facilitate the process. They are:

• Expert Judgment
• Product Analysis
• Alternative Identification
• Facilitated Workshop

A scope statement will include amongst others, the following aspects, described in detailed to ensure the work to be performed is defined correctly”

• Product scope description
• Product acceptance criteria
• Project deliverables
• Project exclusions
• Project constraints

Gathering Requirements, Continued

In my previous post, The Art of Gathering Requirements, we looked at few tips on how to ensure that requirements are collected successfully. For today’s post, let’s look at the list that PMBOK Guide 4th Edition has outlined for the tools and techniques that can be used to collect the requirements. Let’s assume that Kat is the PM and she’s required to meet up with Customer OST to learn their needs for the newly proposed system.

• Interviews
  Interview sessions are normally done one-on-one. Kat will arrange a private that makes it easier for her to know the current situation the customer is in. Strength and weaknesses can be discussed openly. However, this technique can be highly time consuming; thus Kat needs to schedule the session properly and maybe pick a few important stakeholders for this technique.
• Focus Groups
  This technique is similar to interviews but it is done in group. Especially to a specific target group, for example the sales department, or the complains department, etc. Attendees are usually subject matter experts and qualified stakeholders. Kat will be the moderator for each focus group sessions. She could gather the necessary information interactively, however she must be able to maintain a positive climate during the discussion.
• Facilitated Workshops
  Kat can organised workshops between cross-functional stakeholders with she as the facilitator. With this technique, Kat can quickly see the inter-relationship between the departments. She would be able to see cross-functional requirements as well as the reconciling the different needs and expectations. Any issues can be discovered., prioritised and resolved quickly. Similar to focus groups technique, Katy as the facilitator must be able to maintain a positive climate to ensure trust can be fostered.
• Group Creativity Techniques
   
• Group Decision Making Techniques
  
• Questionnaires and Surveys
  This techniques are good for a wide number of respondent. Kat can collect huge amount of data in a brief period of time. With special demographic aspects, she would be able to derive statistical analysis quickly.
• Observations
  With this technique, Kat will sit down with the a user of the current system to see how the actual process is being performed. She can choose to perform “job shadowing” or be a “participant observer” where she is performing the tasks. This technique will be useful for Kat especially with people who are reluctant or have difficulty to articulate their requirements.
• Prototypes
  Kat will also quickly build a prototype with the information that she has currently to quickly get feedback from a working model. Some people can only see what they want when they look at what is being proposed. Several iterations of the prototype can be performed through progressive elaboration for the user to experiment and provide feedback. After the last cycle, the requirements collected would be enough to start building the actual product.

As she gather inputs and feedbacks from users, Kat will use several documents to refer to and to record all the requirements down:

• Requirements Documentation
  Within the organisation, this document is known as Requirements Specifications; where Kat will describe how each of the requirements will meet the business needs. As she collect more data, the document will be updated accordingly.
• Requirements Management Plan
  Kat would have prepared this document beforehand. Reason being, this document will tell her which techniques that she will be using to gather the requirements. She will also plan how the data will be analysed and documented.
• Requirements Traceability Matrix
  This document is essentially a table that links each requirements to its origin so that they can be traceable throughout the project life cycle.

The PMP® Exam is Changing SOON!

Starting from 31st August 2011, the PMP® exam will be different.

Approximately 30% of the content will differ from the current exam format. The Professional and Social Responsibility domain will be tested under all knowledge areas rather than being treated as a separate domain as it is currently.

The eligibility to sit for the exam still remain the same. All the pre-requisites must be met before you register for the exam.

• If you are a Bachelor degree holder, you need to satisfy a minimum of 3 years of professional project experience with 4,500 hours of leading and managing projects.
• If you are a Diploma holder, you need to satisfy a minimum of 5 years of professional project experience with 7,500 hours of leading and managing projects.
• You need to attend 35 contact hours of formal project management education.

Refer to the PMP Handbook for more details.

The new format will still refer to the current PMBOK Guide 4th Edition. 

Exams will still be held at Prometric centers. Check out their website for more information: http://www.prometric.com/default.htm.

To assist in your studying, you can check the following links:

• PMP® Examination Content Outline [LINK]
• PMP® Exam Prep [LINK]

For more information regarding the change, check out PMI’s dedicated page for it here: [Updates to the Project Management Professional (PMP) Certification Exam]

You can also access the FAQ sheet here: [LINK]

Above all, keep up the good work of studying and maintain your momentum. Whether you take the exam with the current specifications or with the new format, if you work at it, you will succeed. Eyes on the prize, people! You set out to get your PMP® certification and that’s what you will get at the end of it. A change in the exam format, will not alter this fact; YOU WILL BE A PMP AFTER YOU TAKE THE EXAM!

GOOD LUCK!

Three Ways To Fail Your PMP Exam Audit

By Cornelius Fichtner, PMP - Making the PMBOK® Guide fun

The Project Management Institute’s (PMI)® Project Management Professional  (PMP)® credential is a globally recognized certification of project management knowledge, skills and experience. So it’s not surprising that PMI takes great care to insure the quality of its certification process, from application through post certification.

When you apply to sit for PMI’s PMP Certification, you will submit a qualification of your education, quantification of your project management experience and classroom hours. If accepted, you can then take the PMP Exam. And if you pass, you’ll be added to the PMI list of certified Project Management Professionals with all its privileges.

You and every PMI certified professional deserves to know that their hard fought credential will retain its value and integrity year in and year out. PMI takes this responsibility very seriously. One of the ways they insure the integrity of your PMP certification is by auditing applicants as well as certified PMPs throughout their programs.

Your PMP application and, later, your PMP Status, can be audited at any time. There are a lot of rumors about PMI’s audit selection criteria, but the truth is that the audit selection process is completely random. There is no control chart of outliers or red flags.

So don’t focus on whether you might fit a truly non-existent profile of someone who gets audited. Focus on making sure your information and actions are aligned with passing an audit from the start! There is a positive and proactive way to approach your PMP application. Take these simple ideas to heart:

Your chances of being audited:

During the application process your chances of being audited are about 50/50 and drop dramatically after certification. Since the PMP Exam audit selection process is completely random, you shouldn’t waste your time listening to and worrying about the rumors of profiling or trigger conditions. Use your energy to properly study for the exam instead and take the time to make your application audit proof.

Being truthful means you don’t have to remember anything:

PMI takes its code of ethics very seriously and so should you. The more time you take to make sure your application is aligned with your experience, the better it will withstand an audit.

Document, Communicate, Align:

Take the time to document clearly your experience. Make sure you know where you stored your degree, training certificates, dates, documentation, contact names, addresses and phone numbers from your projects. Better yet, create a new project folder of all the background information that supports your application.

When you submit your Project Management experience application you will be asked to provide contact persons for each and every project. Be sure to confirm their current email address and phone numbers. These contact persons could be your managers, co-workers, vendors, clients and any other applicable stakeholders from your past projects. Let them know you’re applying to take the PMP Exam. Jog their memory of your projects by sharing with them what you’re submitting and ask them if they agree with what you’ve written. Make corrections if they disagree.

The Three Ways to Fail a PMP Exam Audit:

According to PMI’s Customer Care there are three ways that you can fail an audit: No Fault, Non-Compliance and Fraud. Let’s look at them in detail. First we’ll see what PMI writes for each, then we’ll give you an interpretation and our recommendations.

1.) No Fault

“Cannot verify education or experience through no fault of their own - No suspension period and cannot reapply until candidate can provide the experience hours and document them.”

You should be able to avoid this by making sure you have all your documentation before you submit your PMP Exam application. However, if for some reason, your education or experience cannot be confirmed, through no fault of your own, then PMI will still let you fail the audit. You may reapply as soon as you have your experience hours documented or confirmation of your degree.

2.) Non-Compliance

“Candidate chooses not to attempt audit - One year suspension period”

If you are audited and you simply have too much going on in your life to participate in the audit, then you can choose not to give any audit responses. Similar to pleading “no contest,” the candidate is subject to a one year suspension period before he/she can apply for the PMP Exam again.

3.) Fraud

“Providing False Information - Permanently suspended from sitting for PMI exams.

This should be obvious to you… Don’t lie! It’s not worth it! If you provide false information on your PMP application and you fail an audit because of it, you will be permanently suspended from sitting for any PMI exams. And they truly do mean forever.

If you’re concerned about not having enough contact hours, consider putting off your application until you do. If you’re looking for projects to fill in those hours, there are a lot of volunteer project management opportunities through community service and other non-profit organizations.

If you need a certification by a particular deadline and you’re short of hours, consider sitting for the Certified Associate in Project Management (CAPM)® while you’re accumulating the hours you’ll need for the PMP. A CAPM certification requires only a high school (or equivalent) diploma and either 23 hours of project management education or 1,500 experience hours.

Although PMI can choose to change the PMP Audit process at any time, should you be audited, you’ll be asked to provide copies of your diplomas or equivalents, signatures from people that can verify your experience such as managers and supervisors, and copies of certificates and/or letters from training institutions for each educational course you’re claiming.

The PMP Exam audit process is a hiccup, but not a road block on your way to becoming certified. Take a little care up front, and you’ll come through it with flying colors.

About the author: Cornelius Fichtner, PMP is a noted PMP expert. He has helped over 15,000 students prepare for the PMP Exam with The Project Management PrepCast and The PMP Exam Simulator.

Have You A WBS?

WBS or Work Breakdown Structure is defined as “a deliverable oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project.” [PMBOK 4th Edition, Glossary pg. 452].

A WBS is essentially a mind-map in the form of tree structure that is structured to achieve the main project deliverable. Here’s how it looks like:

The creation of WBS is so important that it is a process group on its own; Create WBS under the knowledge area Scope Management. To create, we will be using the technique of decomposition. Decomposition means to do a breakdown of project deliverables into smaller and more manageable components. We decompose until we reach a component that we can measure in terms of time and cost. The lowest level in a WBS is called a work package.

Each work package will be tied to a control account. A control account is a management control point where scope, budget, actual cost and schedule are integrated and compared to earned value for performance measurement.

A WBS is accompanied by its WBS Dictionary. This is a document that describes each of the WBS components in detail. It will include a brief description of the deliverables, list of activities, list of milestones, etc.

Project Management is a deliverable on its own. Therefore, it has to be depicted in the WBS as well.

The WBS, WBS Dictionary and the Project Scope Statement; together they form the Scope Baseline. The Scope Baseline is one of the important component of Project Management Plan.

So, what is so important about having a WBS? WBS lets you see the deliverables that needs to be accomplished and the components that needs to be completed to ensure the deliverables can be met. Having work packages at the ready and using it alongside the WBS dictionary will ease the creation of schedule, resources management and cost management.

 

[Images taken from PMBOK 4th Edition]

The Art of Gathering Requirements

Most of the time, customers react "violently" towards services or products that is delivered. They seem to be surprised with the outcome, even though they have approved and signed off the requirements specifications earlier on in the project. They will say that they have not requested such and such and what they want is this and that.

Why is this so? Remember this comic:

One important thing to remember is that a service or product to be delivered is based on the needs and wants of the customer; the requirements. Therefore it is imperative that requirements are collected correctly from the right sources. And however we; as the PM; want it, the product is not our brainchild, the project is! So deliver the correct product, the project is a success!

I see requirements gathering process as an art of its own. Reason being, it is not as easy as A-B-C. You need to spend time for it and refine it as detailed as possible. A work of art is not rushed. It is planned carefully; and sometimes changed as the artist deems fit.

Let's look at the strokes that must be done for an excellent finish of an artwork; the requirements specifications.

1. Identify the correct people – Ensure that the people that the requirements are gathered from, are truly the recipients of the service or the users of the product. This people will know the nitty-gritty.
2. Organise a Requirements Gathering Session – If need be, organise a two-day seminar instead of four hours requirements gathering meeting. Arrange different sessions for different group of people, for different types of requirements; functional, non-functional.
3. Ask the users what they want – Utilising techniques like interviews, focus groups, brainstorming, etc. let the users tell you what they want. Most of the time they want everything because they think the need everything. Let them. This is the session where we listen to them. Ask questions to clarify points that are vague, but do not attempt to improve their ideas; this might in the end misled them.
4. Review what the users want – Utilise story-telling techniques, storyboard, flowcharts, tables, diagram, prototypes, etc when reviewing the points collected from the previous session in #3. If possible, organise this review session as soon as possible after the previous session. This is to ensure users are still fresh with their ideas from before. The objective is to understand the points made in #3.
5. Improve the ideas – Separate the needs from the wants. Get the users to prioritise their requirements. Suggest improvements to the ideas to increase the value of the product or service.
6. Agree on delivery phases – If possible, group the requirements and create delivery phases (exclude timeline). Get the users to agree to them. While work is on going, schedule review sessions in each phase to ensure the work done is meeting the requirements. If there is any changes from the users, assess and include accordingly. Remember; while cooking a meal, we check for taste from time to time, to ensure it is as expected. Similarly, perform continuous review on work done to avoid bottle necks of change requests later.
7. Prepare the requirements specification document – James C. Taylor in his book Project Scheduling and Cost Control, listed 8 Tips For Writing Good SOW. Once the document is prepared, review it with the customer, point by point.
8. Get endorsement – Get the customer to sign-off the requirements specification document to show they have understood and agreed to it.
9. Be true to your promises – Some change requests will be shelved for a later phase, or next release. If you have promised this to the customer, make sure you deliver them as agreed. You might want to review again the change requests to see if it is still relevant to the users, but review them you must!
10. Update project documents accordingly – Do not wait until last minute to update the related project documents. If you already have project templates, make use of them; no need to create from scratch.

With this 10 strokes, hopefully the customers will not be surprised the next time they see the completed product for the first time.