Friday, February 22, 2002
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:
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.
- 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.
- 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.
- 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.
Four Noble Truths. Projects are initiated, performed and closed out. It's the perform part that can be distilled into four basic elements:
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:
There it is in a nutshell - eight keys to project success. For specific techniques see my special project management page.
- Start with a WBS. (I've included a sanitized WBS from a service level management project to show how it's done.)
- 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.
- Clearly define what is in- and out of project scope.
- Clearly define each project deliverable in sufficient detail so that there will be no question that what you deliver is what you promised.
- Define client acceptance criteria to which the client or project sponsor agrees.
- 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.
- 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.
- 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.
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:
- 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.
- 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
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:
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.
- Speeding up Service Level Agreement Negotiations
- Reporting for SLM
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
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
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:
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.
- Technology Strategies by Cooper Smith
- IT Systems Management: Designing, Implementing, and Managing World-Class Infrastructures by Richard Schiesser
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.
Monday, February 18, 2002
Overcoming the Power Curve. I've been somewhat elusive lately. Busy actually. I spent a relaxing week in Hawaii the week before last, and my sisters treated me to a mini-cruise out of San Diego for my birthday. Between much needed social activities and chipping away at a mountain of e-mail I think I'm getting to the other side of the power curve.
On My Scope. I've been paying attention to the latest security events, most of which involve Microsoft in some way (no news there).
I've been following Richard Forno's articles in infowarrior.org, among other sources, and it seems as though Microsoft cannot get out of its own way. One of the reasons I'm a Richard Forno fan is he's consistent and his news articles read like a series. Let's go back to November 2001 and read forward:
A wrap-up to the above is the news that Judge grants States access to Windows source by John Lettice, The Register dated 16 February 2002. See Richard Forno's comments in his Linux Security News article of 18 February 2002 titled, Message To Microsoft: Only The Truth Shall Set You Free.
- 10 November 2001 - he debunks .NET in The Freedom to Innovate Includes The Freedom to Obfuscate subtitled, Why Microsoft's New "Security Framework" is Just Another .NET Vulnerability. Prescient? Apparently so when you consider the 15 February ZDNET News Spat over MS 'Flaw' Gets Heated.
- Mr. Forno's 28 November 2001 article titled 'Microsoft,' No. 'Mickeysoft', Yes is more of the same when the "same" is the root cause and the "more" is a list of vulnerabilities.
- We'll fastforward to 16 January 2002 with Richard's The Gates Declaration and Microsoft Security Day, which is skeptical. None other than Bruce Schneier concurs and goes even further in his analysis of the situation, including uncovering a great deal of spin control. It's arguable whether or not Microsoft can build secure applications, but few will disagree that they have mastered spin control. If you don't know who Bruce Schneier is, he's the CTO of Counterpane Internet Security, publisher of the Crypto-Gram Newsletter and the author of Applied Cryptography and Secrets and Lies: Digital Security in a Networked World. In other words, Mr. Schneier is a highly respected expert in the field of security. As an aside, see Kate Hartshorn's 8 November and Mike's 3 January 2001 Amazon review of Secrets and Lies.
The Point. The above is in the same spirit as Mike's 9 February 2002 entry here. Yes, Microsoft gets its share of the heat. In my opinion it's well deserved because social responsibility should be part of the price of being a convicted monopoly. At a time when security is of paramount concern I don't feel that shoddy products filled with reported vulnerabilities are an indication of social responsibility.
However, this isn't about social responsibility either. It's actually a lead-in to the first layer in the Tarrani-Zarate Model that we'll be discussing in subsequent entries. The foundation of that model is business imperatives, and in the next few days you'll see how infrastructure choices should be tied to that foundation instead of being an arbitrary technical decision. Therein lies the point to this entry: had IT been closely monitoring the industry and employing risk management practices, one of two things would have happened:
Points to ponder. It's also the springboard to Mike's next entry, which will introduce business imperatives.
- Microsoft would have long ago been proactive about ensuring their products were not the security risks that have been widely reported.
- Microsoft would have not achieved the monopoly position it currently holds.
Quick Picks. Here are two sites that provide information that is closely aligned to this weblog's goal of promoting IT professionalism:
Irresistible. Mike Sisco (see my 5 February entry) sent me an e-mail this morning letting me know that he has discounted his IT Manager Development Series until the end of the month. From now until then you can order the 10-book collection and his 80-tool IT Manager Toolkit for $179.00. The IT Manager Development Series normally sells for $495.00 and the Toolkit for $250.00, so this limited time offer is a bargain. For more information see the description and ordering page or contact Mike Sisco directly.
- Utopia Place is a resource site for IT professionals in mid-size organizations. This site has a collection of whitepapers that serve as realistic guidelines for its target audience.
- Surrex Solutions also provides valuable resources, with an emphasis on ERP and underlying database systems. They provide a page of links, news and other resources for each of the following: Baan, Essbase, Oracle, PeopleSoft, SAP, Siebel and Sybase. Their newsletter, The Changing IT Landscape is focused on IT management issues.
Simple Path to Success. If you manage software development projects you'll want to download 10 Keys to Software Project Success. This document is a 42-slide presentation (in PDF format) that was given by Steve McConnell at the 12th International Symposium on Software Reliability Engineering.
End Note: Microsoft security is a continuing topic (or soap opera, depending on your point of view). The 15 February ZDNet News article, titled Spat over MS 'Flaw' Gets Heated by Robert Lemos will make you wonder who are the inmates and who is running the asylum.
Late Note - Correction (18:00 US Pacific Time): I was just notified by Mike Sisco that the price of the IT Management Development Series will be $279.00 after 28 February instead of the $495.00 price I cited. I apologize for the mistake.
Sunday, February 17, 2002
Best Wishes. Please join me in a happy birthday wish to Linda. She freely gives of herself to promote IT professionalism through entries here, her role in the family of web pages we maintain, and her insightful and well-written Amazon book reviews. As a colleague I greatly appreciate her collaboration on the countless projects, papers and deliverables on which we work--past, present and future. She is my cherished friend as well as colleague, and one of the hardest working people in IT.
Best Efforts. Linda and I developed the Tarrani-Zarate Model for Information Technology Management during the middle of 2000, and have refined this model in sporadic bursts of ambition over a period of time. What we want to do is to rekindle the work and the best way to do that is to base a series of entries here on each layer in the model.
Someone (and I wish I knew to whom to attribute this) said, no model is perfect, but some are more useful than others. That sums up our model. We know there are flaws, but we also know that it has the potential to serve a useful purpose if we flesh it out and document it better. Describing it will force us to look at it with a more critical eye. From there it may evolve into something more useful.
We welcome your participation as the model's details unfold, and the best way is to join our IT Operations Management discussion on Delphi. You'll need to register with Delphi to participate, but registration is free.
Killing Two Birds. No, we're not going to abuse our feathered friends. What we are going to do is tie the Tarrani-Zarate Model entries here to books in Mike Sisco's IT Manager Development Series. (See my 5 February entry here for more details.)
Ending Notes. Before signing off to enjoy the rest of the day I want to share two online publications that support our goals of promoting IT professionalism: Quality Digest and iSeries Microsite for Software Management. Enjoy your weekend.