February 5, 2010 - PM Value Brain Dump

I am sitting here writing down all the words and phrases that come to my mind in relationship to real Project Management. Here is what I have so far.

Communicating what Matters
Informed Decisions
Change with Purpose
Monitoring Direction
Leading, not just Reporting
Analysis of Activity
Controlling the Outcome
Removing Random Factors
Risk Management
Involved Stakeholders
Enabling Management
Planning Success
Integrity in Action
Confronting Conflict
Lessons Learned
Tension Breaking
Instilling Confidence
Team Defender
Resource Motivator
Promoting Purpose
Follow Through
Critical Thinking
Ownership
Improving... Self, Situation, Team, Understanding...
Challenging... Self, Situation, Team, Understanding...
Results Driven
Business Focused
Influential
Self Controlled

Pieces of this brain dump will be examined more in the next several blogs. We'll ask "What is the result of a project manager being ____?" We will also touch on ways to instill more of these in your thoughts, actions and reactions.

Until then, if you have additional ideas, pitch in by leaving a comment.

March 2, 2007 – Deliverable-based Project Schedules: Part 5

With all the tasks defined and even divided up into deliverable many project managers would be off and running. Truth be told, projects can be successful with the checklist approach. The trouble is a checklist does not allow you to predict when deliverables will be completed, report on the true cost of the project or understand and impact the critical path. I suggest we keep pushing forward, then.

Determine Predecessors. When you are setting up your project schedule, enter the logical predecessors. These are the tasks that legitimately belong linked, like creating the document before you review it and ordering the hardware before you receive and install it. Fake predecessors are based on resource availability or just a random decision because something has to go first. These have their place throughout the project, but not when you are initially setting up the schedule.

The more tasks you can link with predecessors the better your scheduling tool can… well… schedule.

Estimate the Work. You may have noticed we haven’t assigned any resources yet. As you estimate the work for each task, think in terms of 1 person doing the work on that task uninterrupted. So, even if you anticipate it would take 2 people a week to complete a document, set the Work value to 80 hrs. Later we will add the specific resources.

While you are assigning the Work, you are probably thinking of a certain skill level or specific individual. These thoughts influence the estimate. Because of this you should document them as estimating assumptions and include them as part of your proposed schedule. No, this isn’t a fancy word for excuses. If you are expecting an expert Java programmer and end up with a novice, your assumptions were wrong and therefore your estimate will be off. With your estimating assumptions outlined you can recognize the impact and make adjustments accordingly (i.e. more or different resources, additional training, obtain more time, etc.).

March 1, 2007 – Deliverable-based Project Schedules: Part 4

Whether you select a Product or Phase structure, the steps to building a deliverable-based schedule remain the same.

Enter All Tasks. The next step is to fill in all of the tasks associated with the identified list of deliverables. Those deliverables may be the list from the WBS or, like the Phase structured schedule; it may include the separate building blocks (i.e. Requirements Document, etc.).

Drill down to the task level for each deliverables. You can use the WBS or other tool, but eventually you will need to switch to the scheduling tool. Although we are not ready to assign effort to the tasks, the general rule of thumb for the size of a task is between 4 and 80 hours per resources. Anything less than 4 hours is a pain to track and doesn’t offer much payback for the effort. Anything greater than 80 hours is hard to grasp. We are pretty good at understanding and estimating things that can be done in 2 uninterrupted weeks (= 80 hrs). Anything larger becomes difficult to estimate and should be broken into smaller pieces.

Each deliverable should be reviewed with the group or at least the individual that will approve it so include the task Review Deliverable and the milestone Obtain Approval for each one. (Note: a milestone is a task with zero hours and zero duration used to mark an important event or accomplishment.)

Add another deliverable at the bottom of the schedule for Project Management. The tasks under it should include Project Status Reporting, Individual Status Reporting & Time Keeping, Team Meetings, Client Meetings and Management. Some people track project management time as part of each deliverable but it is easier and cleaner to pull it out as a separate item.

The ultimate goal is to have all of the tasks neatly tucked in as sub-tasks under one of the deliverables. Collectively the deliverables constitute the whole of your project scope and anything not part of a deliverable would then be out of scope. However, as you complete your list of tasks, there will be some that don’t seem to fit. There are several possible reasons for this:
1. A deliverable has been missed. Something needs to be added to the scope of the project. If the scope has been agreed to you may need a change request to add to it.
2. The task might have been dumped on you when it should really be out of scope. This might require some push back to define your responsibilities.
3. It may be a legitimate task but the responsibility of another group. You may want to track the completion of the task but not the effort.
4. The process or lifecycle may require the task (ex. creating internal assessment documents, updating review committee checklists, etc.). Since the deliverable is a product of the process, these types of tasks can be incorporated into its creation.
You may have to get a little creative with some tasks, but to effectively use the project schedule to track and report progress you don’t want a rambling task list with no structure.

February 28, 2007 – Updates and Random Thoughts

Unfortunately I left my jump drive in my other computer so the planned blog for today isn't going to happen. Instead I have some updates on the Cutting's Edge and a couple of thoughts jotted down while commuting. The thoughts may eventually turn in to blog entries but they are worth throwing out there to chew on.

First the updates.
Many of you started visiting here because of The PM Podcast (www.thepmpodcast.com) interview on "How can I become a Project Manager?" There were over 6500 downloads of that episode! Cornelius Fichtner does a great job and I would encourage you to visit his site for other topics.

My next speaking engagement will be at the Practical Software Quality and Testing conference (www.psqtconference.com/2007west) on May 9, 2007 in Las Vegas. The topic will be “Avoiding Shock Therapy: A Case Study in Managing Directional Changes.” If your organization of company would be interested in having me speak, let me know (thomascutting@yahoo.com).

Cutting's Edge is closer to being "official." I have filed for a DBA (Doing Business As) in the state of California. I don't intend on quitting my day job any time soon, but....

Finally, Computerworld has accepted an article entitled "Management by Procrastination." Some of you may have read the blog series starting December 1, 2006 that is the basis for it. There isn't a date set for publication.

Two random thoughts.
The first thought is that in order to get ahead in your job and life, you have to hustle. Step up and offer to do whatever needs to be done to take the next step toward your goals. If you are not currently a PM and want to be, ask your manager for tasks to move you in that direction. Entering time and working the project schedule are usually things managers have little time for. It might be a good place to start. Another is taking meeting minutes. In addition to becoming a familiar face in management meetings you gain an understanding of how things work.

The other thought I'll let you ponder. One sign of maturity is recognizing and considering the consequences of your actions.

February 27, 2007 – Deliverable-based Project Schedules: Part 3

[NOTE: For more information, please sign the Guest Book.]

I teach an intermediate level MS Project class that focuses on building a deliverable-based schedule. This concept is foreign to many project managers. They tend to develop and use the schedule solely as a checklist, which is unfortunate because they miss out on both the scheduling capabilities and the reporting information available from the tool. In this next section walks through creating a schedule that will set your project up for success.

Creating the Schedule. There is a certain order to the creation of the schedule. The steps are Enter All Tasks, Determine Predecessors, Estimate the Work, Estimate Duration, Assign Resources and Add Constraints.

But before you begin putting tasks to schedule you need to decide the most appropriate way to lay out your schedule. The answer to this depends on what your reporting needs are. Set the schedule up so that it minimizes the effort needed to extract the information for status and other reporting.

The two main ways to put a deliverable-based project schedule together are (1) by Phase or (2) by Product. You can set up your schedule to switch between the two but it is far too complicated for this venue.

Phase structured schedules follow a standard development lifecycle (Requirements, Analysis, Development, Testing, UAT, Implementation and Support) and divide the main deliverables into pieces that are accomplished in each phase. From our example of the new Home Page, the deliverable for Section 1 would have requirements, analysis, development, testing and implementation. These pieces would be combined for each of the deliverables and called out in each phase. So the Requirements Phase would produce a Requirements Document that would have a part describing the needs of Section 1. The Requirements Document would, in fact, be a separate deliverable as would the Technical Design Document, Test Plans and other combined efforts.

Product structured schedules are strictly set up based on the deliverables identified in the WBS. Each deliverable would be self-contained with Requirements, Development, etc. baked into it. This method is also useful if the deliverables are really unrelated and have no overlapping phases. A simplistic example of this would be scheduling a conference. There are many aspects (ex. Location, Entertainment, Speakers, Catering) that run parallel and are self contained. Each of these deliverables would have milestones along the way to track progress against.
So, although it is tempting to start typing tasks down, it helps to take a look at the structure before you add the substance.

February 20, 2007 – Avoiding Trouble with Honesty

Communication is a huge part of project management. One aspect of it that needs to be practiced more often is honesty. Unfortunately there are times when what we say may be truthful but is far from honest as illustrated in the following examples.

A “User Perceived Bug” is the term Microsoft uses to describe something that is coded to spec but doesn’t work the way any reasonable individual would think it should. I found this out while speaking with support about MS Project’s inability to re-baseline Resource information. They actually said it with a straight face, too.

“Undocumented Features” are those quirks in our systems that aren’t in the specs and somehow sneaked through testing. Who’s to say someone doesn’t want the header on the bottom of the report?

And who hasn’t heard their management say they have an “opportunity” for you when they really mean “problem.” If you hear they have one for you, run away. Fast.

Depending on your environment it can be extremely tempting to divert blame, cover up problems and alter perceptions with our communication. If your workplace is hostile or overly competitive I can understand your dilemma, but my experience has taught me that honesty is the best practice. Here are some warning lights to help keep us honest.
1. If you have to determine how to spin the information, you are on thin ice.
2. When that little voice inside your head says something doesn’t smell right you should listen to it.
3. Any time you say, “I think they’ll buy that” you probably shouldn’t be trying to sell it.
4. If you are trying to pick someone to blame you are heading for trouble.
5. When you say, “I hope management doesn’t find out” you should be the one telling them.

We had a situation once where a developer removed the wrong report from the production system. The natural reaction was to fix the problem, cover it up and hope no one discovered it was missing. The better solution was determine who was impacted, notify them of the situation and get it resolved as quickly as possible. Any time the impacted party discovers the problem, your troubles increase exponentially.

February 16, 2007 – Non-Team Resource Management

At my current engagement there are a number of us that are scattered about as individual consultants on different projects. Being one of the senior people on site I have certain management responsibilities for some that are not on one of my project teams. For consulting this is fairly common. With in house companies this would equate to a very weak matrixed environment where the resources belong to one group but are loaned out to projects with little or no direct supervision from the parent group.

There are a few obvious non-team resource manager responsibilities like approving timesheets and performing annual performance reviews. Because the resources don’t report directly to me for day-to-day activities, this presents a problem. For example, how do I know someone wasn’t out sick on Tuesday but put 40 hours on their timesheet? Or, how do I get feedback for their evaluations? Here are some suggestions to solve these and other problems with this type of environment.

The core to making this work is to build relationships. Contact them in an informal way on a regular basis. If possible the “walk by” management works well. Stop by their desk and ask how things are going and if there is anything they need or problems they have. Phone calls are good for those longer distances and if you can swing a videoconference you get bonus points.

As you start to understand who they are you can begin to understand what motivates them. Although they aren’t directly working with you, any motivation you can provide allows them to satisfy the department or client they are working with.

Training is an important motivational aspect that has two other benefits. First, it gives them additional or improved skills to be more productive. Second, it shows them that they in your eyes they are worth the investment.

Maintain an open dialog with them. In addition to the walk by visits, you can schedule lunches or other opportunities to get together. A problem that can develop over time as the individual begins to think of themselves as part of that other group. Eventually that assignment or project is going to come to an end and the individual is going to feel alienated. This is especially true for consultants.

All of these things feed in to resource retention and must be done proactively. Once there is a crisis or someone decides to switch companies it is too late to fix it. In some cases it could take 2-3 months to retrain someone for that position causing pain for both you and the group they were supporting. Then nobody is happy.

February 15, 2007 – Traits to Manage by

Project managers might stink at politics, ignore tracking tools, flunk PowerPoint and hate spreadsheets but there are three major character traits that they can’t manage without.

Good Communicator. Nearly every aspect of project management involves communication: Risks, Issues, Status, Budget, everything. If you are a poor communicator you will struggle with project management. Some of it is natural ability but, thankfully, there are some steps you can take to become a better communicator.

• Understand that people, especially management, want information. Knowing that may help you overcome some of the anxiety involved. If your upper management is partially sane they will even want to hear bad news, what you intend to do about it and how they can help.
• Reread. If your email is sloppy the audience may completely miss your point. Take time to reread it before you hit send. I often catch things that I write are senseless. I have even left out important words like “not,” changing the whole meaning of the email.
• Plan out your conversations. Think through your meeting agenda and consider how you are going to present it. Jot down key words or phrases that help make the points you wish to say. Anticipate the questions that will be asked.
• Join a group that promotes public speaking. There is an international group called the Toast Masters (www.toastmasters.org) that helps people become better speakers.
• Do more of it. With practice comes ability and confidence.

Integrity. This trait includes honesty in reporting, fair dealings with team members and respect for individuals. Most companies and even professional organizations like PMI have a code of professional ethics or professional conduct guidelines. Read through a couple of them. If you have to hedge or explain away any of the topics perhaps you need to strengthen your integrity.

Thick skin. The role of a project manager is much like that of a lightning rod. You take the heat from management to protect your team, allowing them to do their jobs. Then you get a jolt from your project team pushing back against time lines and direction. Don’t take these things personally. I find it helpful to remind myself that people are upset at the situation people, not me. For example, if the server is down and upper management is yelling at you because of it, they are really upset about the problems it is causing. Unfortunately they can’t yell at the server so you are the substitute.

February 14, 2007 – How Do I Become a PM? Part 4

Note: This series builds on the conversation I had with Cornelius Fichtner, PMP, of The Project Management Podcast. To hear the interview visit www.ThePMPodcast.com and select Episode 062: How can I become a Project Manager?

As we wrap up our discussion on how to become a project manager there are a couple of odds and ends to address.

What about Certification?
Certification is starting to become a must. I interview PMs for my company and one of the things I look for is certification. Although it isn’t a major deciding factor for me more and more companies that advertise on job search sites are requiring it before they even consider you. Experience obviously outweighs certification but with equal experience most employers are likely to opt for the certified candidate.

One of the reasons for this is that certification shows potential employees you are serious about your profession. If you have taken the time, energy and money to get certified you deserve a second look.

Does the type of management matter?
For the most part, the people side of management remains constant whether it is line management, general project management or technical project management. You may be dealing with different types of individuals (ex. Support resources vs. creative, cutting edge developers) but you will still have interpersonal problems to work through.

Line managers generally work ongoing in production or support environments. A project manager by contrast handles “a temporary endeavor to accomplish a unique deliverable” (definition of a project). The focus for line management is to constantly improve the way in which their team does repetitive work. Project managers are more linear with their delivery and may only get one shot at a problem on any given project or phase.

Comparing general project management to technical really depends on the definitions being used. For purposes of discussion let’s assume that a general PM is someone who mainly handles the reporting and financial aspects of a project and a technical PM also works through the mechanics of the project. Using these definitions I consider the general PM role as a weak one. Even when I manage project that I lack a technical background in, I quickly come up to speed in order to understand talk to the issues in that industry’s language. If I have to haul a techie with me to every meeting, she isn’t going to have time to do her own job.

One problem with a technical PM is the temptation to try and do the actual work. When things get tough, inexperienced PMs have the urge to fall back onto what they did well before getting promoted. If they were once strong programmers the tendency is to pick up a keyboard and start coding again.

Can a PM do any type of project?
Although project management techniques are universal, I would be hard pressed to successfully manage the construction of a bridge. Having a background in the area you are managing is important. My brother, Andy, is a foreman on steal building construction. No one is going to let us switch places for the day.

However, within your industry there can be lots of room for movement. I grew up performing Cobol and ‘C’ / Unix programming yet I’ve managed web development, testing and other engagements well. Having the background doesn’t mean you are an expert; you just need to be able to adjust to the industry specific language the team uses.

February 12, 2007 – How Do I Become a PM? Part 2

Note: This series builds on the conversation I had with Cornelius Fichtner, PMP, of The Project Management Podcast. To hear the interview visit http://www.thepmpodcast.com/ and select Episode 062: How can I become a Project Manager?

When Should I Start?
Having grown up on the technical side of the aisle, I am probably biased, but I think it is important to get experience before attempting to manage. Not only does it give you a good understanding of how your business works, it also gives you a chance to mature as an individual.
During Y2K company’s were short on PMs. I remember an instance when we partnered with one of the “Big 5” consulting companies to remediate a DB2 database application for a large financial institution. The PMs from the other firm were fresh out of college and it soon showed. Their glorious solution was to download all of the data to Excel, run a macro to change the fields and then reload it to DB2. The amount of data that needed to be converted far exceeded anything that Excel could have handled. Needless to say the technical team’s and the client’s confidence in their management abilities dropped quickly.

How do I get there?
If you have decided that project management is the right career move you should Prepare, Position and Perform your way into the role.

Prepare. Take classes, read books and get a better understand of the profession. You can do this while still gaining your experience. The more you learn the more it will either confirm or dampen your decision to become a PM.

Position. Being in the right place at the right time is key. Consider taking a project coordinator or administrator role as a stepping-stone to management. Working for a consulting firm gave me the ability to move around while maintaining my benefits with a stable company. Be up front with your management and let them know what your career objectives were.

Perform. Begin using the skills you are developing. Most of your assignments can be treated like a project. Define it, Plan it, Track it and Report on it.

• Define it – Document the request and present it back for verification. Don’t get too fancy or long winded. Keep it simple and clear.
• Plan it – Develop an approach for accomplishing your assignment and lay out a schedule with hours, dates and duration.
• Track it – keep a record of how much effort you put in and how it matched up against your dates and estimates.
• Report it – Even if you company doesn’t require status reports from team members, issue a weekly status report to your manager.

If you are a developer, the key is to do these things so that they don’t interfere with your “day job.” Keep them simple (ex. 1 page definition, high level plan, and 1 page bullet pointed status report). If your management questions the amount of effort you are diverting from your real work, consider do it after hours.

Another great training ground is an organization like PMI or another nonprofit organizations. There are always projects that need to be done. Treat them like projects and use them to develop your skills.

February 9, 2007 – How Do I Become a PM? Part 1

Note: This series builds on the conversation I had with Cornelius Fichtner, PMP, of The Project Management Podcast. To hear the interview visit http://www.thepmpodcast.com/ and select Episode 062: How can I become a Project Manager?

Do you have what it takes?
Project management is not for the faint of heart. You may currently be in a techie, analyst or other non-management role and are looking at project management as the next logical step in your career. I remember thinking that it was all about telling people what to do and taking the credit. I was also young and naïve.

The first step in the direction of becoming a PM is to decide if it is really something you want to do. Not everyone is cut out for it. The role of a project manager is much like that of a lightning rod. You take the heat from management protecting your team and allowing them to do their jobs. Then you get the jolt from your project team pushing back against time lines and direction.

To be a good project manager you need to be a great communicator, a good motivator and have thick skin. Nearly 90% of project management is communication, including creating reports, presenting status, getting information from your technical staff and giving direction to the team. Certainly those traits can be learned, but if you have no interest or inclination toward them it will be difficult for you to make it in the management world.

Technical people tend to think that moving to management is the only logical progression for advancement. That isn’t as true as it used to be. With the number of different skills and technical areas of expertise available people can specialize and advance technically while have a very rewarding career. I recently had an applicant for a Telematics position who’s normal consulting fee is about $200 / hour. So if your passion is technical, management probably isn’t the direction you want.

How did I become a PM?
I grew up in the technical ranks from programmer to business analyst and then on to PM. I’ve even done a couple of stints back on the technical side along the way when needed.

There were two types of PMs that influenced my desire to sign up as one. The first group made it look easy. They knew how to plan, direct and manage the business. It was work, but they almost made it look easy. The other kind were those that struggled the whole way. They barely pulled things together and just managed to squeak by in the end, over budget and out of time. The first group encouraged me by proving it was possible. The second group made me think I could do a better job than they did.

I was fortunate enough to work for a large consulting company that valued project management and encouraged me along the way. They trained me, gave me an opportunity and mentored me through it. Timing had a little bit to do with it, too. My first PM assignment came during the Y2K adventure. There were a lot of projects and not enough managers.

February 6, 2007 – 5 Questions PMs should Ask

Nearly 90% of Project Management is communication. From status meetings to project plans, scope statements to presentations and resource issues to crisis management we are constantly communicating. In order to do this successfully we need to ask the right questions. As a follow up from the previous entry entitled “5 Things Not to Say During a Meeting” you need to ask these 5 questions instead.

What are you thinking?
Unless you are a mind reader, finding out what your business group and end users want can be as frustrating as this question. When gathering requirements this question needs to be asked multiple times and in various ways. The objective is to fully understand the business problem and any clues to the solution they may have.

Are we there yet?
If you have ever traveled with children you have heard “Are we there yet?” a thousand times over and over again. The answer should be obvious to anyone since the car is still in the same traffic jam it was 3 minutes ago when it was asked. While it is annoying for a 5 year old to ask it, it is one of the top 5 questions Project Managers should be asking the team. The answer to this question gives you the current status of the effort but, if asked in the right way, can also keep the project from over delivering. If your programmers forget to stop where they are supposed to and deliver more than what was asked for it could put you over budget and out of time.

How much farther?
It doesn’t matter how many times you calmly explain how much longer it is going to take, upper management always wants you to get there sooner. As a project manager you need to know where you are and how long it is going to take to get to done. Your team members are the only ones able to give you an honest answer. As part of the status reporting process, ask the team to re-estimate major tasks every week so you can adjust the Estimates to Complete.

What is your problem?
Most people take offense when this question is asked. The job of the project manager is to eliminate problems and keep obstacles out of the project’s path. By asking the question early and often you have a chance at staying ahead of the issues.

Why?
This is possibly the most annoying question of all time. “Why” makes you dig to understand the purpose behind a comment or request. In Change Management the question is used determine the real intent and necessity of the new request. For Issue Management it forces people to get to the root cause of the problem. When dealing with interpersonal issues it makes you dig beyond the current conflict. The answers to “Why?” can be painful if the result is that someone has to admit their shortcomings.

When you ask any of these questions with the right amount of agitation in your voice and a bewildered look on your face you run the risk of being slapped. You might want to change the wording, but make sure you get the right answers.

February 5, 2007 – 5 Things Not to Say During a Meeting

Every now and then I say things that get me into trouble. I’ll be sitting in another exciting meeting and that part of my brain that is supposed to keep me from making a fool of myself falls asleep. It usually happens when the facilitator has allowed someone to monopolize the discussion or the topic is going nowhere.

Based on those types of meetings I have learned that there are certain things you shouldn’t say. Here are 5 things you will want to add to your list:

1. “Four out of the five voices told me your idea really stinks.” Although it may be true, no one likes a dissenting voice. Obviously if the voices in your head were all in agreement you wouldn’t mention it. Besides, “stinks” is such a harsh word. Try something like “I have some misgivings about your idea.”
2. “You’re not the boss of me.” This is especially true if the person you are saying it to is your manager.
3. “Whatever” sarcastically while holding up 3 fingers like a “W” and then turning them to look like an “E.” I’ve found that the proper use of fingers during conversation is tricky. Besides, technically “whatever” is one word so it would just be a “W” which wouldn’t mean anything to anyone.
4. “As far as you know.” Although this is an honest answer to a question, chances are it will just confuse them and make people upset.
5. “I see your lips moving but all I hear is ‘blah, blah, blah.’” If you choose not to listen to someone, simply nod your head and smile.

If any of these things happen to spill out of your mouth there is one trick that may save your bacon. Look truly surprised that you said it and add, “Oh! I’m sorry. Was that out loud?” Maybe you can pass it off as one of the voices in your head.

February 2, 2007 – Managing the Thing: Acceptance Management

The third leg in our attempt to manage The Thing is Acceptance Management. The purpose of Acceptance Management is to gain approval of the project one piece at a time. The concept is that the successful completion of each of the deliverables adds up to a successfully completed project. The process actually began back in the Project Definition Document. The deliverables defined there are the building blocks for the overall project.

In the PDD you defined each deliverable with acceptance criteria and approval authority so you would know when that piece of the project is complete and who is to verify and accept it. When a deliverable is completed, it is presented to the approver(s) for review and a Deliverable Acceptance form is issued to formally accept it. If it meets the criteria listed in the PDD it should pass. If it doesn’t it should be rejected with a list of specific reasons and returned to the team to fix. In the event that the deliverable meets the specified criteria but not the expectations of the approver, then you need to understand what changed and potentially issue a Change Request to bring it back into alignment.

The Deliverable Acceptance form should contain the following fields.

Project Number and Name states which of the multiple projects you are managing and the approvers are reviewing.

Deliverable Number and Name identifies which part of the project is under review. These should match exactly back to the PDD to avoid any confusion. At the end of the project you are going to go through the PDD and demonstrate that you delivered everything you said you would.
Approvers, as stated in the PDD. Give both the name and the role. If you remember, in the PDD you listed the role that was expected to approve the deliverable. That is because the people fulfilling roles may change during the course of the project but the role should remain constant. NOTE: the changing of resources on the project should be communicated with a Change Request to align the PDD back with reality.

Date Submitted and Date Reply Due represent the date you review the deliverable with the approver(s) and the date 3 to 5 days beyond that. In the Acceptance Management section of the PDD you need agreement on the exact number of days to review and approve deliverables. Since deliverables tend to build on each other the work you perform for the next part is at risk until the current deliverable is approved. As an example, if the Data Base Architecture document isn’t approved any work done to create the data base may change drastically.
Requestor is usually the project manager.

Description of Deliverable should be a cut and paste from the PDD. Keep that in mind when you are writing the statement in the PDD. It may make it easier to determine what to write.
Acceptance Criteria is also cut and paste from the PDD.

Finally, a statement such as “If this Deliverable has met the Acceptance Criteria as specified above, please respond to this email stating that you approve. If for some reason this Deliverable does not meet your expectations, please respond stating that you Disapprove and give the specific reasons for your dissatisfaction.”

As with Change Management, approval can be sought electronically or with hard copy signatures. Email seems to work best, but don’t use Outlook’s response buttons. They only return approved or disapproved and don’t include the original email with the response. For both project clarity and SOX purposes you will want the response to clearly state what was approved.

The Thing doesn’t stand a chance of getting delivered successfully if it isn’t:

• Defined,
• Allowed to change with the business needs, and
• Approved upon completion.

While I was fixing virus infected PCs I realized that the urgent details of the project were keep me from clearly communicating what was to be delivered. If you do the same you may end up delivering the coffee and donuts for UAT.

February 1, 2007 – Managing the Thing: Change Management

Change is normal and healthy. Consider your socks. It is normal, healthy and advisable to change them on a regular basis. The same is true as we manage The Thing. Expect change. Encourage it. But most importantly, manage it. Managing change involves identifying what constitutes a change, documenting the change and obtaining approval of it.

Identifying Changes. The Project Definition Document is the basis for identifying change. There are two types of change: Scope and Non-compliance. Scope changes include any variance from the original, documented and approved project direction. These are usually pretty obvious and include:
· Adding or removing functionality.
· Incorporating new responsibilities (i.e. overseeing the progress of related projects).
· Changing the project schedule.
· Modifying the budget for funds added to or removed from your project for any reason.

Non-compliance changes are caused when people fail to meet their obligations or circumstances cause an impact to the project. These are less friendly because they can seem petty or may not be the fault of anyone in particular. For example, one of your project assumptions was that the testing environment was to be created by the Infrastructure Team by a specific date. If that doesn’t happen by the time you are ready to begin testing it will impact the project. A Change Request should be issued to adjust the timeline and associated cost.

Documenting Changes. Anyone can identify and request a change. In my experience it is usually the project manager who ends up documenting them. A standardized form, or Change Request, should be created for documenting changes. The following fields should be included in order for the key stakeholders to decide if the changes requested are warranted and if they are willing to fund them.

Project identification. The form should include a section to identify the Project Number and Name, Requestor, Submission Date, Reply Due Date and Approvers. Also add a spot for Change Number. Chances are you will have more than one. It is helpful to include the Change Number in the name of the document.

Description of Change. Briefly describe the change that has been requested.

Justification for Change. Document why this change is necessary. Will it increase the ROI? Shorten the pay back time frame? Enhance the functionality in some critical way?

Effect on Project Scope. Identify whether you are adding, removing or modifying items from the scope. If you are adding a new deliverable, document it just like you did in the PDD. If you are adding or subtracting from an existing deliverable, outline the requested changes.

Effect on Deliverables, Schedule and Cost. Perform the necessary analysis to forecast what this change will do to the project schedule and cost. If the change is to an existing deliverable, use the same deliverable name and document the revised end date, changes in hours and cost increases or decreases.

Approvals. Gaining approval of changes is at least as important as getting initial approval of the PDD. The Thing will change with or without an approval, but with approval you can know that the change is agreed to. In the change request form, include a section for approvals. If your approval method is via email, add a statement to the form saying, “Approval is required from the following individuals” and list their names. For wet signature approvals, actually make lines for people to sign.

Who actually approves a Change Request should be documented in a couple of places in the PDD. The Roles and Responsibilities section should list the authority levels for certain types of approvals. Most companies have approval levels based on the amount of money being expended. Even though all stakeholders do not have approval authority, it is important that they are aware of changes as they happen and are able to offer their input.

Two last thoughts about managing change. First, do not begin any change until it is approved. It is a recipe for disaster. Continue as if nothing has changed until signed. Second, if a Change Requests is not approved by the due date, it should expire. Your analysis of the project impact was based on a point in time. A week later you are further down the project and the same change may require backing out previously coded effort or reworking pieces that were already tested.

January 29, 2007 – Managing the Thing: Project Definition Part 3

Most of the topics that I cover could fill full books and several classes. I barely touch the surface and hopefully point you in the right direction. Even in the brief way in which we are discussing Project Definition it has taken 3 different entries to complete. Today will cover Roles and Responsibilities, Milestones and Budget, and the Management Approach.

Roles and Responsibilities. This section identifies the roles of specific resources involved in the project and outlines their responsibilities. Major miscommunications and unmet expectations can be resolved simply by clearly setting responsibilities here. Build a table with the columns Role, Name and Responsibilities. It is important to identify a specific individual with each role. Also, the Responsibilities column, as with Out of Scope section, offers you the opportunity to state what you expect others to do. The example below is for the Business Team Leads but you should also identify the Sponsor, Overall Project Manager, other Team Leads, external vendors and other key roles.

Role
Business Team Leads

Name
Heather Morgan (Demand Planning)
Jillian Enaile (Supply)

Responsibilities
· Represent their business unit on the project.
· Provide project status to Overall Project Manager and upper management.
· Identify and assign appropriate individuals to participate in JAD sessions.
· Review and approve the Design document, UAT, and Final Approval.
· Coordinate all aspects of UAT for their business unit, including test plan and test scripts creation, execution, and signoffs.
· Etc.

Notice the use of verbs to describe what is expected. Imbedded in the Responsibilities is another clarification on the UAT ownership.

Milestones and Budget. This section, as the name implies, identifies the major milestones and deliverables with planned start and end dates and estimated cost in dollars, hours, or both. This needs to align with the Project Schedule. By developing the schedule and PDD together you can perform checks against each of them to keep them synchronized. If you identify a deliverable in the Approach section, it should correspond with a group of specific tasks in the schedule. Similarly, if you have activities identified in the Project Schedule you need to account for them in the SOW.

Management Approach. Depending on the maturity of your organization the size of the Management Approach section may vary. It outlines how each of the following areas will be handled and sets the expectations up front.
· Communication Management – identifies reports produced and meetings held (ex. Weekly Status Report and Weekly Status Meeting).
· Issue Management – shows expected level of issue documentation and resolution plans, giving a specific path for escalation.
· Risk Management – documents how risk identification and mitigation and how when contingency plans are necessary.
· Change Management – describes what constitutes a change, how to document it and the approval process.
· Acceptance Management – gives direction on how to approve or reject deliverables and timeframes for doing either.

If your organization has any or all of these management approaches defined, do not recreate them here. Reference them and document any deviations that your project will follow.

These six sections (Background, Scope, Approach, Roles and Responsibilities, Milestones and Budget, and Management Approach) form a basic Project Definition Document. Depending on your environment and project needs, the level of detail and legal jargon that is required will differ. The concept remains the same: Define The Thing that is to be delivered. Set the project expectations in writing and then obtain formal approval of it. As we will see in the entries to come, this document forms the basis for both change and approval.

January 26, 2007 – Managing the Thing: Project Definition Part 2

Without defining the project, The Thing will likely fail to get accomplished. It will consume more time than anticipated and accomplish less than expected while costing more than it should have. When the wide variety of documents are boiled down to their simplest form that basics that need to be communicated are the Background, Scope, Approach, Roles and Responsibilities, Milestones and Budget, and Management Approach.

Project Background. The background is meant to describe who requested The Thing, what it is, why they requested it, and how the team arrived at the current point. A successful background is short and correctly spells the name of the person that requested it.

Scope. The scope section documents exactly what the team is responsible for (In Scope) and, just as importantly, what it is not (Out of Scope). Items should be identified clearly. As an example, “Support of User Acceptance Testing” does not clearly set expectations. You may be thinking, “make sure the system is up, answer a few questions, and fix anything that fails.” What the Sponsor may read between the lines is, “create the test scripts, train the testers, and supply coffee and donuts.” A better scope statement might read:
Support User Acceptance Testing by ensuring that the system is available, refreshing test data, recording defects and tracking corrections, and facilitating daily UAT meetings.

The Out of Scope portion further refines the expectations by addressing items that a newbie to the project might otherwise assume were the team’s responsibility. Examples would include:

• Training testers on the use of the system is the responsibility of the Training Department.
• The UAT Test Scripts will be developed by the Business as directed by the Business Project Manager.
• Bring your own stinking coffee and donuts.
  

Well, maybe the last one shouldn’t be in the final document.

Approach. The approach outlines the Technical Environment, Development Life Cycle and Deliverables.

Technical Environment. Is this web development or COBOL, JAVA or Infomatica? Clarifying this up front will set everyone’s expectations. This is not a Technical Specification so give a high-level overview and refrain from details of how the parts interact and perform.

Development Life Cycle. What phases or process will be followed as the project unfolds? Will you do prototyping, execute a pilot, or use JAD sessions to drive out requirements? Briefly define what the involved parties can expect.

Deliverables. This is the real substance of this section. In some cases it may make sense to have a separate section for it. Deliverables are the building blocks for the project and serve as checkpoints to verify progress. The sum of all of the deliverables should constitute the whole project so it will be helpful to develop a Work Breakdown Structure (WBS) to identify the all.

Each deliverable should be listed with its name, description, acceptance criteria, and approval authority. Below is a good example of a deliverable statement.

Name
Statement of Work

Description
This document defines the project by identifying the Scope, Deliverables, and Roles and Responsibilities. It is an agreement between the involved parties and forms the basis for project expectations.

Acceptance Criteria
The document contains the following sections:
1. Background identifying the request and brief history.
2. Scope of the project.
3. Approach with Technical Environment, Development Life Cycle, and all Deliverables identified.
….
Each section clearly articulates the expectations of each stakeholder.

Approval Authority
Project Sponsor
Business Project Manager
IT Project Manager
Manage of Sales

A good way to present this information is in a table. Notice how in the Acceptance Criteria lists the specific sections we have discussed. As we will see in the Acceptance Management section, those criteria are what the approver should be verifying when deciding whether or not the deliverable is done.

In the next entry we will cover the remaining sections of the PDD.

January 25, 2007 – Managing the Thing: Project Definition Part 1

The first key piece to successfully delivering The Thing is defining the project. PMI identifies three major documents that are used to do this:
1. The Project Charter grants formal authority for the project.
2. The Project Scope Statement documents what work is to be accomplished and the deliverables that need to be produced.
3. The Project Management Plan documents how the work will be performed.

If you think that the Project Management Plan is the same as the project schedule you would fail the PMP exam. A full Plan includes sections or even separate documents that lay out how you will manage the Scope, Schedule, Cost, Quality, Staffing, Communications, Risks and Procurement.

If you work for a company that doesn’t have this level of maturity yet, I would suggest creating a condensed version and calling it the Project Definition Document (PDD). Think of your project as a big sandbox where everyone is trying to build a castle. You need to know the rules of the sandbox and what you are building. That is the purpose of the PDD. By agreeing up front what you want to accomplish and how you are going to accomplish it, the complete team (Sponsor down to the coders and testers) can shovel sand in the same direction. Once completed the PDD should be reviewed and approved by the key project stakeholders (i.e. Sponsor, Project Manager(s), Business Manager, etc.).

I worked at a company where defining the project in writing and getting it approved was not encouraged. The reason became apparent as additional items were added to the scope. Project managers struggling to create detailed PowerPoint presentations for the overall project status. It had to cover aspects of the project they had no control over and little visibility to. The PM was stuck doing it because there was no documented understanding of the division of responsibilities and no authority to delegate it.

Tomorrow we will begin to look at the six areas that should be included in the Project Definition Document: Background, Scope, Approach, Roles and Responsibilities, Milestones and Budget, and Management Approach.

January 24, 2007 – Managing to the Thing: Introduction

Several years ago I volunteered to participate in a massive PC cleanup effort after a company wide virus attack. At the time my project deliverables were behind schedule and the virus was putting me further behind. As a Project Manager, that is not a good feeling. It was less than a month after returned to project management from the Software Quality Assurance group and I could feel the pressure from both sides. In my mind the SQA group was saying, “Finally, someone who knows the processes and can show those Delivery people how to do things right!” Meanwhile my new Delivery co-workers were rooting, “All right! Now one of them is going to find out just how difficult it is to follow their processes!”

While I was checking and installing virus protection in multiple buildings with several floors that night I had plenty of time to think about the things I wasn’t getting done. My new day job was proving to be very tiring as I attempted to stay on top of the wave of activities. I was trying to juggle everything, rushing from meeting to meeting, jumping from task to task and not completing anything. The strain of the urgent had choked out the basic principle that I knew: You have to define it before you can accomplish it.

Central to successful project management is delivery of the end product, or The Thing. In order to do this effectively, three key pieces need to work together: the Project Definition*, Change Management, and Acceptance Management. Over the next several days I want to outline the main aspects of each of these and show how they form the basis for project success.

Why these three? The Project Definition, Change and Acceptance at their core are simply communication vehicles. When used together, these three:
· Define The Thing that is to be delivered,
· Allow The Thing to change,
· Let everyone agree that The Thing is completed.

Without communicating these three, projects would go on forever without satisfaction for anyone.

*Project Definition – The defining document(s) for the project. Consulting companies use the Statement of Work. Internally it may be a Charter or the Scope Statement together with the Project Management Plan.

January 23, 2007 – Avoiding the Idiot List

I have a renewed dislike for stupid drivers. A buddy and I have been carpooling. Here in Southern California the freeways have carpool lanes with limited access at well-marked areas to enter and exit and a $300 fine for violators. On heavy traffic days you can sail along past the other three lanes, which are generally standing still. That is where the stupid drivers reside with their blatant disregard for the law, safety and my sanity. Obviously the regulation must not apply to them so they swerve into the lane in front of us.

Unfortunately there are idiots at work, too. Try to avoid these annoying actions and you won’t end up on anyone’s idiot list.

Not backing your team. Two of my co-workers were complaining to me one day about their manager. She was new to the group and had a completely different philosophy of management. The previous manager focused on enforcing the standards, even when it meant standing up against upper management. The newbie correctly identified the rift between the groups but assumed it was the fault of her new team. It took the team nearly six months before she came around and started supporting them.

Playing the dumb blond. During my auditing days there were certain females that thought if they batted their eyelashes and pretended to be helpless I wouldn’t be as hard on them. Granted, not all of them had blond hair. I treated them just the same as everyone else, but I might have spoken slower and use smaller words.

Ditching your own meeting. A friend of mine had a manager that scheduled a daily 7 AM phone conference for status meetings. That might be enough to get on my list but that wasn’t the worst of it. The manager didn’t show up for the first two meetings and left everyone sitting on the phone for 20 minutes until they gave up and left. The third day he called in late and was on the freeway heading for the airport. No one could hear him and there was little chance of him remembering anything. Worse, he never even apologized. My guess is he was swerving into the carpool lane.