Friday, February 22, 2002

 
Posted by Mike Tarrani 4:07 AM
Crossover. In my 20 February entry in Notes from the Field I briefly touched upon some of the success factors that need to be satisfied in any project. Because the topic is more applicable to this weblog (Notes from the Field is where we address software and systems engineering topics; this weblog is for IT professional improvement), I am going to continue the topic here.

Project Management - the short version. I've been managing projects for nearly 25 years. Not just IT projects either. I've managed ship repair projects, where a cost overrun or two among friends is not nearly as career-killing as missing a schedule milestone. When a ship is scheduled to get underway it better do just that.

Setting the Stage. There are three stages in a project manager's career:

1. Mastery of techniques. These include the basics: work breakdown structure (WBS) development, estimating techniques, critical path method (CPM), program review and evaluation technique (PERT), precedent and activity diagramming, scheduling algorithms, compression techniques and , earned value, and a plethora of other tools of the trade.
2. Recognition that it's all about people. The techniques that need to be mastered will get you only so far, as you quickly discover after you've mastered them. You begin to understand that it's all about managing people, and your leadership skills begin to emerge. You also discover that you need to be able to communicate, delegate responsibilities and authority, and to hold people accountable. You also develop polished political skills and become adroit in manipulation and coordination.
3. Enlightenment. After you've managed successful projects and a few disasters you will eventually reach a state of enlightenment where you clearly see that project management is about making sure that your backside is covered. This is done with the techniques you've mastered, and the people and political skills you've developed and honed.

The problem with IT project management in most cases is [so-called] PMs skip step 1, gloss over step 2 and focus on step 3. There are no shortcuts to Nirvana. You need to get there in stages.

Four Noble Truths. Projects are initiated, performed and closed out. It's the perform part that can be distilled into four basic elements:

1. Plan
2. Estimate
3. Schedule
4. Control

This does not diminish the importance of project initiation and close-out procedures, nor does it conflict with the key processes set forth in the Project Management Body of Knowledge or PRINCE2 (both of which have been discussed in previous entries).

The Eightfold Path. There are eight tools that I've found to be essential to successful project management:

1. Start with a WBS. (I've included a sanitized WBS from a service level management project to show how it's done.)
2. Have the people who are going to do the work estimate the time it will take. Resist the temptation to pull numbers out of thin air - it's the surest way to cost and schedule overruns. An example estimating worksheet is included in a ZIP archive of project management tools that also include deliverables management and fixed-price contracting presentations that you may find useful.
3. Clearly define what is in- and out of project scope.
4. Clearly define each project deliverable in sufficient detail so that there will be no question that what you deliver is what you promised.
5. Define client acceptance criteria to which the client or project sponsor agrees.
6. Do not deviate from the scope or defined deliverables without an approved change order. Never! See the example change request for what one should contain.
7. Ensure that each deliverable is signed for by the client or project sponsor (or designated representative). See example deliverable receipt for a sanitized copy of one that was used on a real project.
8. Keep all stakeholders informed. This includes the client/project sponsor and team members. All stakeholders should have a statement of work! Especially the rank and file workers who are performing the actual work. All stakeholders should also receive a copy of status reports, which need to be published at least every two weeks, and in many cases on a weekly basis.

There it is in a nutshell - eight keys to project success. For specific techniques see my special project management page.

Under the Bodhi Tree. The Bodhi Tree is known as the tree of wisdom, and is located in Bodh Gaya, India. There's an easier way to get project management wisdom, and that's by reading a few selected books. So, instead, travel to Amazon and get one (or both) of these two highly recommended books:

1. Getting Started in Project Management by Paula K. Martin and Karen Tate. See Linda's 15 December 2001 or my 17 December 2001 review to see why we so highly recommend this book, especially to occasional project managers. It does not bog you down in unnecessary details or overly complicate project management.
2. Visualizing Project Management by Kevin Forsberg, Howard Cotterman and Hal Mooz. This is the book that I recommend to beginners and experienced project managers and is, in my opinion, the best book ever written on the subject. See Linda's 16 March 2001 review (well worth reading) and my 7 December 2000 review for details.

If you have questions about project management, want to share your experiences, techniques and thoughts, or want to discuss PM in general please join our Project Management Forum. Free registration is required to post.

Thursday, February 21, 2002

 
Posted by Mike Tarrani 11:28 PM
Goals. One of the basic tasks in which we all engage is goal setting. This is a fundamental part of project management, strategic planning, and even personal career management. One excellent resource that I recently discovered is Peter de Jager's newsletter (he also has a page of miscellaneous articles on goal setting.)

Service Level Management. NextSLM.org has new articles on service level management that are clearly articulated and are on the mark with respect to excellence in service delivery. The two newest articles are:

1. Speeding up Service Level Agreement Negotiations
2. Reporting for SLM

NextSLM.org is the web site that supports Foundations of Service Level Management by Rick Sturm, Wayne Morris and Mary Jander. The site keeps the book up-to-date, and is one of the places I look for SLM and SLA reference material. Linda reviewed the book on Amazon on 27 December 2000 (it was her first Amazon review) and I reviewed it on 19 June 2001.

Security. One of the recurring topics is security, and if you've read any of my entries you'll frequently come across the term Common Criteria, which is shorthand for Common Criteria for Information Technology Security Evaluation ISO/IEC 15408. You can visit the official Common Criteria site, but if you're new to the Common Criteria, I recommend that you first visit the tutorial track page from the First International Common Criteria Conference. You can download all of the tutorials in a single ZIP archive. Each tutorial is in PowerPoint format.

End Note. Kate Hartshorn and I will be collaborating on a business intelligence web site in the near future. Stay tuned.

Wednesday, February 20, 2002

 
Posted by Mike Tarrani 9:48 AM
Agree With One, Disagree With the Other. I just finished two Sticky Minds articles that got my attention.

I Agree. The first article, by Johanna Rothman is one that every software quality team member and manager, as well as business process owner and governance member should read: What Does It Cost to Fix a Defect?. Ms. Rothman steps you through the cost analysis and decision points for determining if a defect should be fixed or lived with. It is, after all, a business decision, and her approach will help to determine if it makes sense to fix a problem or not.

I Disagree. The second article, by Brian Beaver, is titled Categorizing Defects by Eliminating 'Severity' and 'Priority'. In essence Mr. Beaver proposes that severity and priority be replaced with a single category: business impact.

Severity is too fine-grained of an attribute to be cast aside. In fact, a definition of severity is the degree of impact a problem has on business operations.

For example, the following are severity levels that are defined in a typical problem management process:

• Severity One - Loss of application, or critical performance degradation, with no workaround. Incident affects an entire workgroup.
• Severity Two - Moderate application degradation incidents. Severity One workaround. Incident affects several customers.
• Severity Three - Minor application degradation incidents. Incident or request has medium to high impact on single customer's ability to work.
• Severity Four - Incident or request has a low impact on single customer's ability to work.

Severity without priority would mean that a mission-critical application falling into the Severity Two classification would be given the same business impact rating as one that is less critical. How does one prioritize in that case? See the gap?

The gap can be closed by assigning a criticality rating to each system, application and service in an enterprise's portfolio. Linda and I developed a spreadsheet for determining criticality. Criticality does not replace severity definitions, but is useful for arriving at a system of priorities that is based on how important an application is to an enterprise.

Where Mr. Beaver's premise and mine differ is in our viewpoints. He is on the technical side, concerned with fixing defects, and I am on the service level management side ensuring that tools and services are there when users need them to meet business objectives. We're both right.

In an issue management scenario that requires coordination between applications and service delivery, life would be simple if we could assign a single rating. However, IT should not be the group that determines what gets fixed and when it gets fixed - that's up to the business. It's their systems and applications. We're the custodians. Without a priority rating, which is determined by the business (ideally under the cognizance of governance), the judgement would be [wrongfully] left to IT.

Assuming all else equal, there is no way to assign a business impact without severity plus criticality. Even then there needs to be arbitration for competing requirements sharing the same business impact, and priority is the way to fairly arbitrate.

That said, I do admire the fact that Mr. Beaver is thinking in terms of business impact instead of IT impact. I also admire the way he has developed a line of thought and has taken the time to document it and share it with his peers. That is what fostering professionalism is all about.

End Note. I also downloaded an interesting paper by Dave Lutzker titled, Testing Is a Phase, Quality Is an Approach. In a single page Mr. Lutzker captures the essence of quality vs. testing. It's a quick read and well worth the time to download. The paper is from Sticky Minds, which is one of the best software QA resources on the web. Most of the articles take a business approach, and the content is first rate.

Tuesday, February 19, 2002

 
Posted by Mike Tarrani 9:06 PM
Development Critical Success Factors. The Department of Defense-sponsored Software Program Managers Network has been one of my long time sources of best practices. Over the past few years they have distilled down to 16 critical practices what is essential to successfully developing software. You can download the 146-slide PowerPoint presentation on these 16 critical software practices, as well as get a whitepaper in MS Word format.

Two New Books The Harris Kern Enterprise Computing Series has two new additions:

1. Technology Strategies by Cooper Smith
2. IT Systems Management: Designing, Implementing, and Managing World-Class Infrastructures by Richard Schiesser

Here's a hard-to-find bonus: Participate in a survey (you'll first have to go through a free registration process), and you can select one of the series books as a free reward for your efforts. The offer is, unfortunately, limited to survey takers in the United States.

End Note. As a prelude to my entry that introduces the Tarrani-Zarate Model I'm sharing an excellent article titled, Grammar of Goal Setting. This will set the context for the business imperatives layer of our model. A well-written companion article is Common Goal Setting Tangles.