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 26, 2007 - Please Stand By

"Please Stand By." We used to get this message on our TV screen when I was a kid. It was usually due to technical problems at the station, but with only 3 stations broadcasting you didn't have much choice.

Unfortunately I am having to ask you to stand by for the next installment of this series. I was writing it last night and my thoughts kept going around in circles. The concept of creating project schedules gets complicated quickly when you are trying to boil it down to less than 500 words.

I'll give it another shot tonight. It may just be a case of breaking the topic into smaller chunks.

Until then, thanks for standing by.

Thomas Cutting, PMP

PS. InformIT.com published an article I wrote on this subject. You can check it out at Building a Manageable Schedule Part 1 and Part 2.

February 23, 2007 – Deliverable-based Project Schedules: Part 2

[NOTE: If you have not taken the opportunity, please register in the Guest Book to receive information about an upcoming give away.]

The first step in developing a deliverable-based project schedule is to determine what those deliverables are. One tool used to do this is the Work Breakdown Structure (WBS).

Work Breakdown Structure. The WBS is a planning tool that documents the breakdown of the project into deliverables. The is accomplished by taking the ultimate product of the project and breaking it into smaller, more manageable pieces until you have identified all the building blocks of the project. If that project were to create a new home page, the final deliverable would be the completed page. Simplistically speaking, the development process could be divided into parts that included Layout, Column 1 and Column 2 with each of the columns further defined as illustrated in the picture below.





Get the team involved in this exercise. As the project manager, you should facilitate and document these brainstorming sessions. The key is to know when to stop drilling. One indication is based on the fact that deliverables are nouns. If you start listing verbs you are at the activity and task level and should stop. There may be a couple of key tasks you want to jot down as a reminder but you aren’t looking to detail the tasks at this point.

There are multiple ways to capture this information. Initially the diagram method works well for a whiteboard session. Using a spreadsheet or document works, too. Although it may seem logical to use a project-scheduling tool it may be premature. The tool will prompt you for more information on each piece and distract you from getting the team’s ideas out.

From our example the deliverables identified were the Design, Format, Sections 1, 2, 3 and 4. Each of these can be defined and handed to an individual or team to create.

February 22, 2007 – Deliverable-based Project Schedules: Part 1

[NOTE: If you have not taken the opportunity, please register in the Guest Book to receive updates from the Cutting's Edge.]

People build many different types of project schedules. There are the massive checklist and the one liner varieties. I’ve seen them with Phases, Activities, Tasks, Sub-Tasks, Sub-sub-tasks and sub-sub-sub-tasks. Some have randomly bolded Milestones and still others fail to communicate anything.

For projects that span more than a couple of months and a handful of individuals, a deliverable-based project plan offers the best way to track and report on it. Over the next several entries we’ll look at:
1. Definitions
2. Work Breakdown Structure (WBS) – what it is and how to use it
3. Creating the Schedule
4. When is enough too much?

Definitions. Since there are 3 words there are obviously 5 definitions that we need to review.

Deliverable – pre-defined, tangible work product. This could be a report, document, web page, server upgrade or any other building block to your overall project. The size of a deliverable may depend on the size of your project, but typically they should be between 4 and 6 weeks in duration and spread evenly across the project length. There is another huge discussion we could have on acceptance management at this point. Check out the entry of February 2, 2007 Managing the Think: Acceptance Management for more on the topic.

Project – temporary endeavor to produce a unique thing. That thing can be a product, service or some thing.

Schedule – tool that defines what tasks are to be done, by whom and when. This is different than a Project Plan, which explains the need for the fourth definition.

Project Plan – formally approved document that lays the ground rules for how the project will be managed. The schedule management is a part, but it also includes change management plan, risk management plan, resource management plan and other pieces to guide project execution and control.

A Deliverable-based Project Schedule then is a tool to define and track the delivery of a unique product or service. Ideally all of the activities and tasks within the project will roll up to be part of the one of the project’s deliverables. Any tasks, then, that is not part of a deliverable may be out of scope for the project.

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 13, 2007 – How Do I Become a PM? Part 3

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?

In our attempt to become PMPs, we have checked to see if it really is what we want to do, decided that we should probably get some technical grounding and discussed preparation, positioning and performing. But how do we move it forward faster?

What might help speed up the process?
Of the 3 Ps from the previous section (Prepare, Position and Perform) the one that will move things along faster is position. Here are several suggestions to put you in the right place at the right time.

Networking. The saying “it isn’t what you know, it’s who you know” is alive and active. Just like auto mechanics and plumbers, people hire individuals that they either know or who have been recommended by someone they know. Join a project management group and make friends. Keep in contact with former co-workers. I still call people I have worked with in different states. You never know when those contacts will connect you with your next opportunity.

Move in the right direction. This actually has two connotations. First, take positions that move you toward a project management role. Roles like Project Coordinator or Project Administrator can be very valuable steps. You get to see project management up close and personal without the front line responsibilities.

The second is to physically move. I‘m not suggesting you go as crazy as I have. My family and I have moved from Cleveland, Ohio to Syracuse, New York and now we are in southern California. You can move within your own company while maintaining your years of service and other benefits.

If you are a consultant or work in a large organization this will be easier to do than if you are in a small shop. It can be difficult to break out of your job rut when you are with a small company. You become know as the Java programmer or, worse yet, the COBOL man. There aren’t as many opportunities for you to try your wings. I managed a project in a hospital that had a very small IT department. The people working there were not going to advance very far there because there wasn’t anywhere to go. They would need to seek opportunities elsewhere.

Eat your vegetables. Actually that won’t help but your mother was reading the blog and sent me an email saying to remind you.

Raise your hand. Let your management know that you are interested in moving up. Show them the steps you are taking and ask them to help map out a plan. Be prepared for constructive criticism and, if you are lucky, mentoring. If they laugh really loud or consistently say “no” it may be time to move on.

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 8, 2007 - This Day Intentionally Left Blank

I have been working on a couple of side projects and haven't had the chance to blog as often as usual. There are 2 things in particular that I am finalizing.
1. Last night I recorded an interview with The PM Podcast (http://www.thepmpodcast.com/) that will be posted on Saturday. The topic was How to Become a Project Manager.
2. I have been accepted to speak at the Practical Software Quality and Testing conference (www.psqtconference.com/2007west) in May.

Thank you for your patience. I'll get back into the swing of things shortly.

Thomas Cutting, PMP

PS. The direct link to the synopsis for my presentation is at www.psqtconference.com/2007west/display.php?id=Thomas_Cutting_Avoiding_Shock

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.