January 24, 2010 – Driving me Crazy!

Having a GPS in the car drives me crazy. I do not operate well with directions that come one step at a time. It may be the Project Manager in me, but I want to see the big picture and know where I’m heading. Besides, at 65 miles an hour, I can’t judge “300 yards before taking the next left.” I’m not even sure if “Miss Voice” means her left or mine.

I realized this last week as I was traveling to a client site with our main sales person. She was driving and I was trying to navigate. We were attempting to go from Orange County, CA near Disney to the Pasadena area, home of the Rose Bowl Parade. The final destination was between the 60 and Interstate 10. I know how I would go and assumed the GPS would use the same route, straight up the 605.

Imagine my confusion when Miss Voice said, “In ½ mile, take exit to Interstate 5 North.” Before I could wrestle the screen to show the projected route, we had swerved onto the exit ramp to follow the directions. It was either that or face the dreaded “Recalculating…Recalculating” reprimand….or worse, the “Make a legal U-Turn” snide remark.

Through a comedy of errors, we managed to get back on track. We missed the 60, but found Interstate 10. Following Miss Voice’s advice, we passed the exit bearing the name of the street the client was on and took the next exit. I had a general sense of where we were heading by then and expected to head south and then east. Miss Voice, however, took us north and then west until we realized the ending address had changed.

I personally think Miss Voice was so disgusted with us that she was thinking, “Fine! If you don’t appreciate me, I’ll drive you to a back alley where you’ll get car jacked. They’ll strip this vehicle down and sell me to someone that can follow directions!”

Some project managers run their projects using a GPS. They punch a predefined address into their Charter and start driving. They fail to look far enough ahead to get into the right lane before missing the turn. Ultimately they allow the project direction to be altered without their knowledge, ending up somewhere else entirely. Even if they avoid a devastating collision, the sponsor usually ends up with car sickness.

Here are the top 10 ways to reach your destination without throwing your GPS out the window.

10. Lay out the full map. Understand where you are headed. You don’t need to know the turn by turn details, but you want to be able to sense when you are going in the wrong direction.

9. Verify your destination. Review the scope and requirements with your stakeholders and obtain their approval.

8. Keep an eye on the gas gauge. Budget, time and resources have to be planned and used appropriately.

7. Listen to Miss Voice. If you have laid out your plan and schedule accurately, follow them.

6. Track your progress. A GPS uses your current speed and position to calculate arrival time. Analyze your progress and spend rate to make sure you are on schedule and budget.

5. Look for landmarks. Set milestones in your schedule. Use them to validate your direction with stakeholders and gauge your timing.

4. Check the map frequently. Verify progress against the scope and requirements in order to stay on course.

3. Recalculate. As the project progresses, more information is available. It may be refined requirements, new technology, resource changes or other factors that impact the end product. Use formal change processes to re-evaluate and alter the direction and cost.

2. Check the traffic. Analyze the risks in your project. If it appears there is traffic ahead, take action to avoid it.

1. You have arrived at your destination. Recognize when you have completed the project’s scope. Don’t allow random course changes to be slammed in at the end of the project. These tend to be less structured, lack adequate testing and overrun the budget.

We arrived in one piece, but it is a good thing we left early.

February 1, 2009 – Going Covert, Part 4

NOTE: On January 12, Computerworld published an article I wrote entitled Covert PMO. This series of entries is a fictional account based on the Project Manager in that article. Any resemblance to anyone from my past, present or future is purely coincidental. To start at the beginning, jump to January 1, 2009 – Going Covert, Part 1.

Day 16, Friday – Wow! It’s Friday already. Payday is always nice. Technically it is already spent, but it is nice to have it pass through my bank account. It makes me feel like I’m doing my part to stimulate the economy.

The follow up schedule review meeting with the team went well. I wouldn’t have guessed thinking in terms of hours would be such a culture shock to them. Given the hours they estimated and their availability on my project I was able to project a realistic timeframe for delivery: 112 days. That’s a bit longer than the 83 days originally planned and certainly not happy news for Management on Monday.

I ran a couple of different scenarios, checking the critical path, and came up with some options to present to Management. It isn’t rocket science. We can (1) extend the date; (2) decrease the amount of work; (3) increase the number of resources or some combination of the three.

We’ve already been told the data is fixed. When the CEO sets a date, it stays set.

Since we haven’t finalized the requirements we may be able to adjust the scope of the project.

Adding new resources would slow us down on an already crunched schedule. Our best bet is to get more time from the resources assigned to the project.

Day 19, Monday – Meeting with Management went almost as expected. Why is it that something that seems obvious to me is a mystery to Management? Calculating the length of a project is simple mathematics. If the number hours your resources have doesn’t equal the number of hours left to complete the project, the date is going to slip.

Fortunately, after the “I’m so disappointed in you and your PMP certification” speech and then getting grilled with questions, management opted to pull my resources off their other projects. If, in fact, they are allowed to, it will effectively cut our duration by a third and place us in range to meet the deadline.

The surprise additional action they took was to add a Finance report for invoicing purposes. They need to know the total number of records sent to the Clear Mind Counseling Center. Not a big report, but I’ll put a Change Request in within the next couple of days after we estimate the effort.

The other PMs picked Tuesdays to informally get together and talk through our projects and problems. Our first meeting is tomorrow

Day 20, Tuesday – Finished off the estimate on the finance report and sent it out for approval. I wrote it up and attached it to an email, asking them to respond with an “Approved” or send it back with the reasons why not. I receive two phone calls asking what I meant: one from the Business Project Manager and one from the sponsor. Evidently the business doesn’t normally get involved at this level.

It was a great conversation starter, though. I suspect I’ve opened Pandora’s Box. After I explained that a Change Request outlines what is requested and how it impacts the cost and schedule, her interest level was raised. The business is likely to start asking for more involvement going forward.

The phone call from Management started with, “What are you thinking?!?!? We don’t send Change Requests to the Business!” I guess that was another one of those written procedures they got rid of without telling anyone in the PMO.

The PM meeting over lunch went better. Since they still think of me as belonging to the PMO, I was expected to head up the meeting. I started by recapping my first 20 days. My whining consisted of:

• No documentation on management of project including the Project Schedule and Charter.
• The fact that the deadline was set before anyone really estimated the effort.
• Requirements were incomplete.
• Lack of resources and those that I had were over allocated.
• Management status meetings more like firing squad.
• Unrealistic expectations set and held by management.
• No opportunity to re-estimate based on more knowledge of the project.

They agreed with my list and added:

• Project managers running too many projects (one guy had 7!).
• Developers adding “little” items to the project that are found in Testing as defects because they don’t match the requirements or design.
• Business not offering any input until User Acceptance and then they want to change everything.
• No agreement on requirements.
• Failing Sarbanes Oxley (SOX) related Internal Audit checks and having to rework things.
• Information Security (InfoSec) reviewing the product and demanding changes at the end of the project.

In a way it felt good to collectively get it off our chests but it left us feeling empty. Not quite hopeless, but certainly depressed. We decided to think through what we did on our own projects to address these issue and get together next week to start sharing them.

When I got back to my desk I received another curve ball. The Business Project Manager sent me an email saying there was another company they were starting to work with that offered different services. She wanted to know if we could send the same feed to another company.

Our schedule is so dead.

Jump to Part 5.

August 4, 2008 - Failure to Manage

Our house recently went through some medium size renovations. It began with replacing the hot water heater with a tankless model. During the installation the plumber explained that our galvanized pipes were badly corroded. In some places the rusty build up was seeping through to the outside of the pipe and in other it was clogging the water flow.

Scope change #1: add $5500 to re-pipe the house using copper.

Since they were taking the shower wall apart we opted to rip it out and tile the entire bathroom.

Scope change #2: another $3500 + materials.

It finished with the “Since We’re Here” special: I was in the process of digging up my front lawn to install sprinklers and they offered to run the pipes.

Scope change #3: $800 + materials. Good thing we recently refinanced!

Instead of going with a company, I hired a couple of independent contractors. They did a great job with the work, but there was a lack of basic project management from the beginning. That failure to manage caused disappointment, minor frustration and more work for me:

• The hot water heater went in smoothly, but the promise to run the wire and mount the thermostat went unfulfilled.
• The bathroom and shower look terrific, but when they said they could raise the shower head above 6 feet, I thought they were actually going to do it.
• Refitting the house with copper was a success except for a minor design change. They originally planned to come up through the floor instead of the wall. Evidently they changed their minds and now I have big holes in my walls were the pipes come out. Evidently they don’t do drywall so now I have to.
• Removing the old shower and other trash evidently wasn’t in the plan, either.

Technically, I got more than I paid for. They charged quite a bit less than they could have, did a solid job and the bathroom alone increased our house value by more than the cost of the whole project. But if I had it to do over again I would have applied more project management myself by:

• Defining the Scope. There were several items I assumed were in scope that I ended up doing: wiring an outdoor electrical box; removing old pipes from under the house; disposing of garbage; and filling the holes in the walls to name a few. I’m sure it would have increased the cost of the project but at least communicating it up front would have prepared me for it.
• Identifying all requirements. As the “sponsor” this one was my fault. When they replaced the main water line to the house they dug under the sidewalk to connect it at the meter. Had I told them I was looking to add a sprinkler system we could have used that same hole and saved some digging.
• Documenting Changes. A potential problem was averted by writing down the prices quoted to me and verifying my understanding.
• Establishing Timelines. It seemed to take forever to complete all the projects. There were scheduling conflicts on our side and theirs that stretched the duration.
• Tracking Commitments. Every time I take a shower I will likely think, “I should have reminded him to raise that pipe.” As for the thermostat, I finally hung that to the wall today.
• Customer Satisfaction. The ultimate item a project manager would have brought to the mix was a better customer experience. Small details matter, like placing a runner on the floor to minimize tracking dirt across the floor; letting us know arrive and departure times; and setting expectations.

With the help of a project manager, I have no doubt these guys could double their work load and obtain great referrals every time. Then again, I’m probably biased.

July 20, 2008 - Random Thoughts

While on vacation I am pulling together a chunk of my blog entries to publish in book format entitled Project Management RX: 101 Daily Doses. This hasn’t left me much time to sit down and write anything new, but I did have a couple of random thoughts to pass on to you.

Red, Yellow, Green. The often used RYG symbols indicating project status risk levels have proven very useful. But what if you were sitting at a stop light and the color never changed? It can be very frustrating. Sometimes I am tempted to jump out of my car and press the crosswalk button to make it change. For your project, anything other than Green should be temporary, too. Items causing your project to be Yellow should be resolved within 2 weeks. For Red issues, fast action should be taken to back it down to Yellow within 2-4 days.

Intolerable. While mentoring projects managers I occasionally hear the statement, “I guess we just have to live with it.” We cave in on many issues and inconveniences, including poor performers, additional scope, old resources, impossible time lines, or slow responses from other department. We feel like there is nothing we can do to stop it. Instead of whining about it, here’s a suggestion. Document the items as change requests and present them to the sponsor and PMO. Explain the impact to the project and receive their buy in stating that they are okay with it. When they see it in black and white it will be harder to ignore, forcing some action to be taken. If you put up with it, nothing will ever change.

January 6, 2008 – Same Old Same Old?

I know. I’m a little late on the "welcome to the new year" thing. But as I sat down to write my blog tonight it struck me that we have a full new year in front of us. I’m not one to create huge goals or make great predictions, but think of the possibilities. If you have been waiting to get certified, this may be the year to do it. Sick of your old job? Find a new one. Stuck in a rut? Climb out.

Two thoughts to begin the year with:

1. Is this the type of _____ you want to be known as? Fill in the blank. Project Manager? Husband? Friend? Person? What is it that people know you as, or you feel like, that you no longer want to be. Tired of being the quiet one? Late one? The one that doesn’t have the monthly reports in on time? If people think they have you pegged, prove them wrong.

2. _____ is important enough for me to _____. Is there anything important enough to you that you will change your behavior? Decide what it is you want to make significant in your life and then do something about it. Many people live their life day to day without changing anything. Maybe it is your dignity. Would you say, "My dignity is important enough for me to walk out of a meeting the next time my director chooses to degrade me"? Or "My future is important enough to me to get certified"?

Go take on the year.

December 17, 2007 - Use Case Diagrams: A PM's View

Last week I attended a class on managing requirements with Use Cases. It was aimed at training business analysts and programmers to use Unified Modeling Language (UML) to understand and communicate business requirements . As a project manager I found it both enlightening and encouraging.

Enlightenment. Bottom line, modeling requirements is the quickest way to work with the end users and agree upon of what the system should be designed and developed to do. Because our focus was requirements, the class used Use Case diagrams as the basis for the training.

The three main components of a Use Case diagrams are the Actors, Use Cases and Scenarios. Actors are represented by stick figures, Use Cases by ovals and Scenarios by text boxes. An Actor is a role played by either humans or other systems that interact with the system being built. A Use Cases is a complete series of events handled by the system to help the actor achieve a goal. Scenarios detail how the Use Case will achieve those goals.

In one of my training sessions I use the eXtreme Insurance company as the basis for the exercises. The company is creating a new system to support the sale of life insurance policies to extreme sports nuts. These policies will be sold by cashiers of D&L Sporting Goods stores. The diagram above details the Purchase Policy use case. Other use cases that would be added to this diagram include Process Claim and Reconcile Transactions.

These quick, graphical representations are developed from information gathered through interviewing the users, observing system usage, researching similar systems and other means. The diagrams are then reviewed with the business to verify understanding, accuracy and completeness of the system. Gaining this clarity early in the process is cheap. Waiting for feedback until a prototype or, even worse, User Acceptance Testing may result in costly rework.
Encouraging. The encouraging part of this class was the way the instructor used Use Cases as a means to establish a requirements baseline and discuss change management. Remember, this was a class designed for analysts and programmers. By moving the discussion to their level, the Project Manager wins powerful allies for managing scope. Analysts can better identify the required functionality and processes, lower future surprises and rework. Programmers start to recognize gold plating as anything that isn’t specified in the use cases. When the business begins to ask for additions or changes, clarification begins with revisiting the diagrams and understanding what is different. Those differences become change requests to be processed by the Project Manager.

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

November 29, 2006 - Surviving Directional Changes Part 4

So far we have set ourselves up for success and discussed improving while remaining constant to the purpose. Both of these prepare us for changes as long as we see them coming.

Recognize Change. Change is inevitable…unless you are buying coffee at Starbucks with a ten dollar bill. Within the context of surviving change in the QA group there are three kinds of change that I’d like to discuss: Contractual Changes, Organizational Changes and Hidden Changes.

Contractual Changes are obvious when they happen but the impact may not be evident at first. An easy consulting example of this is if your contract switches from fixed bid to a time and materials. If in the original contract the QA group was a non-billable feature it needs to be recognized and billed for or the group will soon be terminated. Our original contract included obtaining CMM Level 3 within 1 year. This forced our focus for the first 12 months was on achieving that. If our contractual agreement changed, our focus and perhaps our charter would have had to change, too.

Organizational Changes may occur without you knowing it immediately but can still have a big impact on the group. If new business management results in a heavier focus on SOX related items, your continuous improvement muscles might get stretched. If the new focus is away from process and more on speed, you will receive more push back from the development teams. As organizational changes happen it is important to identify them and begin looking for clues on their impact. We ran in to this when our direct QA manager changed. The focus moved from the corporate SQA group as our sponsor to the local management as our “client” and ensuring they were satisfied. This shift resulted in substantial changes in the way we operated.

Hidden Changes are a pain in the butt. You find out about them by accident like the party in high school you weren’t supposed to be invited to. Someone says “didn’t you know? Oh, um, never mind.” It happens during audits when the PM says “we’ve been told not to do it that way any more.” Or when someone comes back from the Architecture Review Meeting and informs the team that there is a new requirement to replace all Java code with Mocha Latte.
The best way to catch these changes is by putting yourself in the right places. Get yourself invited to development department meetings. Create a PM Forum where project managers can share war stories, complain and transfer knowledge. Pay attention during audits to the excuses for noncompliance.By setting yourself up for success, continuously improving while focusing on your purpose and recognizing changes you will be able to prolong the usefulness and impact of the QA group.

November 27, 2006 - Surviving Directional Changes Part 2

In a quest to build stability in your team 3 key activities were identified: Set yourself up for success; strive to continuously improve; and recognize change and the impact it will have on the group. Identify your sponsor was the first step to setup for success.

The second is to recognize the stakeholders. Among the stakeholders for our QA group included the Corporate SQA manager, the on site consulting management and the project teams. Our group was expanded to include the Project Office role we also trained, mentored and audited the project managers so they also became key stakeholders.

Of course recognition involves more that just naming them. Documenting the relationship and responsibilities the group has toward these individuals leads directly into the next step, create a charter and obtain approval. This formally identifies the group, draws the boundaries around their responsibilities and grants the authority to perform those duties. This is another point where the level of authority of your sponsor is important. If it is too low the charter won’t be enforceable.

The final step in setting up for success is to communicate the group purpose and objectives. It is important to let the key stakeholders know what you are charged with accomplishing. This was especially important in our group. There was a need for Quality Control function to verify the final product; however our charter outlined our responsibilities as Quality Assurance focused on ensuring the processes were defined and followed. When our purpose was questioned we returned to our charter to make sure we were meeting the group objectives.

November 22, 2006 - Surviving Directional Changes Part 1

Last night I had the privilege of speaking to the Orange County Southern California Quality Assurance Association (http://www.scqaa.com/ ) about surviving directional changes. The presentation focused on lessons learned by the Quality Assurance group at one of Keane’s largest AO engagements.

This particular Quality Assurance group combined responsibilities of the project office and the process definition and audit group. Their focus was on training, mentoring and auditing project managers to ensure that projects were performing according to the documented procedures. In order to gain and maintain stability in a changing environment the group had to do 3 things: 1. Setup for Success
2. Continuously Improve
3. Recognize Change

Setup for Success. The first key to a successful start is to identify your sponsor. The sponsor is the person you derive your authority and direction from. Ideally for a QA group the sponsorship and reporting structure should be different than the one for the delivery team. This alleviates any pressure to alter or water down the auditing if the results reflect poorly on your own management. It gives the group a route to report decisions and actions that may place the company or project at risk.

After the Thanksgiving weekend we will take a look at each of the remaining keys to setup for success.

Have a happy Thanksgiving.