Monday, December 24, 2007

December 24, 2007 - Twas the Night before Christmas

Technically it is the extremely early hours at the beginning of the day before Christmas. I've just spent the last several hours wrapping presents with my wife and listening to music. Rather than making a half hearted attempt at writing something intelligent I will simply wish you a Merry Christmas.

"And there were shepherds living out in the fields nearby, keeping watch over their flocks at night. An angel of the Lord appeared to them, and the glory of the Lord shone around them, and they were terrified. But the angel said to them, 'Do not be afraid. I bring you good news of great joy that will be for all the people. Today in the town of David a Savior has been born to you; he is Christ the Lord. This will be a sign to you: You will find a baby wrapped in cloths and lying in a manger.'

Suddenly a great company of the heavenly hosts appeared with the angel, praising God and saying,

'Glory to God in the highest, and on earth peace to men on whom his favor rests.'"

Luke 2:8-14

May you seek that great joy and know true peace.

Merry Christmas from the Cutting's Edge.

Sunday, December 16, 2007

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.

Sunday, December 9, 2007

December 10, 2007 - Burnt by Hiring a Newbie

As an account manager for various clients, I have had to hire project managers to fill open slots. The hard part is separating the bad from the good. One agency I worked with promised me a solid project manager as a replacement for one that left. When he arrived I sat him down and started laying out my expectations for scheduling, status reporting and other normal activities. It was met with a blank stare. From there the conversation went something like:

Me: "So, have you managed a project before?"
Newbie: "No, but I have been the lead on several initiatives."
Me: "Have you had any project management training?"
Newbie: "No, but I’ve worked on a similar system before."
Me: "Did you know you were supposed to be the project manager for this project?"
Newbie: "They mentioned I might be doing something like that."
Me: "Why is it you are here?"
Newbie: Blank stare.

When I called the agency I was assured they had a lot of confidence in him because he was, and I quote, a "high performing technical lead." With service like that it comes as no surprise to me when clients complain about receiving the bait and switch – promised a solid Project Manager and getting a rookie. How can you prevent it? Ask the right questions up front.

Here are three basic questions to ask before accepting a PM for your project:

1. What and when was your last project management assignment?
Your first clue of a potential rookie would be if they talk about their great technical lead rolls. See if they can articulate the business purpose for the project and why it was a challenge for them. Get a flavor for the overall size, duration, number of resources they managed.

2. How did you manage the cost, schedule and scope of that effort?
This questions will test their ability to speak in project management terms. The phrases you are looking for are:

  • Established the budget (cost)
  • Used the Work Breakdown Structure to develop the deliverables and lay out the schedule (schedule)
  • Created a baseline and established milestones (cost / schedule)
  • Tracked actual work and estimates to complete by resource at the task level (schedule)
  • Compared the progress and costs back to the baseline (cost) with bonus points if they mention critical path or earned value
  • Defined the scope in the Charter, Statement of Work or other defining document
  • Used Change Requests to identify and approve deviations from the scope

3. When did you schedule status meetings and who attended them?
Status meetings fall into two categories. The first is with the team to gather the status. The second is with the sponsor and other management to convey that status. From my experience at the end of the week you have the team status meeting, collect timesheets and status reports. On Monday the project schedule is updated and the weekly status report is create and sent out. Tuesday is then the day for the sponsor status meeting. The information is fresh and you have a current view of the forecasted project.

Solid answers to these 3 questions will give you a good comfort level of your candidate’s ability. Keep them honest by asking for some of the struggles they dealt with in implementing their tactics.

If you have additional questions that would help weed out rookies before they are hired, share it in a comment.

Sunday, December 2, 2007

December 3, 2007 – Lacking Commitment

They stripped a month off my project. Okay, technically I misunderstood them when they said go-live was September. What they meant was there would be a month long parallel run in production before they turned off the old system in September. Either way there were four less weeks of development time.

After sketching out the timeline, System Testing was scheduled for July 18. The four weeks to that date didn’t look long enough to me for the interface team. I wanted desperately to return to the steering committee with evidence to support my suspicions, but when asked, the team assured me it would be ready. Every status meeting I checked. Between meetings I followed up. Always the same answer: “We are on schedule.”

On July 17 we had the pre-System Testing meeting to tie up loose ends, the interfaces being one of them. The technical lead smiled and said with confidence, “We finally did it. The design is complete.” Yes, he said DESIGN! During the somewhat heated discussion that followed it became clear that they were no where near ready to test. The code didn’t even exist. They had said the words but had never committed.

Obtaining Commitment. Before anyone can (or should) commit to anything they need to know what they are in for. Walk through the expectations with the team that will do the work. Ask them for their estimates, timelines and constraints. Deadlines I impose can be dismissed as unrealistic but if the team develops the dates they own the estimate and associated commitments.

Scheduling Commitments. Before finalizing and announcing any dates, put a schedule together to lay out the commitments. Ideally you would use Primavera, MS Project or other tool to detail phases, deliverables, activities and tasks with planned hours and baseline dates. Even without those you can still put a meaningful schedule together. At a minimum, break the effort into pieces (ex. Interfaces A, B and C) and sketch out the tasks to complete them. Lay out the timeline based on the commitment and assign resources to the tasks.

Tracking Commitments. If your team has matured to the point of using actual hours and estimates to complete to rework the plan on a weekly basis, consider yourself fortunately. Many companies aren’t there yet. For everyone else, you can work it using the due dates and percent complete. Each week have the team report on which tasks are completed and the percent complete of started ones. Also have them review the task end dates and confirm they are still realistic. If a task slips, check the ripple effect and have them determine how to get back on track. Projects usually fail at the task level. Keep them in line and you stand a chance of completing on time.

Breaking Commitments. Sometimes commitments can’t be kept. Your team has to know they can tell you when they can’t meet a date. For whatever reason, my interface team waited until it was too late. By communicating the progress along the way adjustments can be made. Scope can be altered. Resources can be added. Alternatives can be discussed. When communicating the disappointing news to your management, have your facts in place. Instead of just saying, “We can’t make it,” spell out:
· Cause of the problem.
· Plans to get back on schedule.
· Proposed new dates.
· Steps to keep the problem from happening again.
· Help needed from management.

To solve our problem we ended up bypassing the interface engines by generating test material until they were completed. With significant sweat and long weekends we were able to meet the aggressive September timeline with a shortened parallel run.