This page is powered by Blogger.


 
  corner   



HOME

ARCHIVES

SEARCH

Contacting Us
Recommendations
Mike Tarrani
Linda Zarate
Kate Hartshorn

Who We Are
TEAM Zarate-Tarrani

Our main weblog
Notes from the Field

Our other pages
Mike's home page
Linda's home page
Kate's home page

Forums
Simpatico [we]blogs
Dan Gilmore
Robert X. Cringely
Jakob Nielsen
Julian Bond
Deborah Branscum
Lisa Rein
CamWorld
Ed Yourdon

 

Friday, January 25, 2002

 

Maxims

I'm in a soapbox mood at this late (or early, depending on your perspective) hour. Left unchecked I tend to write missives, but sometimes a few words have as much power as a few paragraphs, especially when the words are to plant thoughts and restate those obvious facts that we sometimes lose sight of in our daily grind. Hence, the following potpourri of maxims--rules born of lessons learned and experience--addressing topics in no particular order.
Project Management
  • A task without an associated deliverable adds no value to a project.
  • If you don't start your project planning with a work breakdown structure you'll have to eventually develop one in order to rescue the project.
  • If you're 15% into a project and you're already 15% off your schedule or cost baseline you will not recover (I wish I could remember the source of this one, but I can assure you that it's true).
Service Level Management
  • Never allow a change to be made to a production system without sign-off by the business process owner(s) for whom the system is designed to support.
  • Do not close out trouble reports until the individual who submitted the report agrees that the problem has been successfully resolved. The issue can be marked as completed and awaiting sign-off, but never closed.
  • Systems are owned by the business, not by IT. We're the stewards and keepers of the system, not the owners. Business process owners have the final say with respect to maintenance windows, changes to the system and should have the authority to waive procedures, such as testing, if business imperatives so dictate. IT is responsible for explaining the risks of bypassing procedures on a case-by-case basis, but the business process owners should have the right to decide their own fate (in writing, of course).
Policy, Process and Procedure
  • Policies that cannot be enforced should not be created.
  • Any IT policy should:
    1. be traceable to business goals or imperatives
    2. be developed as a collaboration between IT and the business
    3. have executive sponsorship at the company officer level
  • Policies govern processes, processes are performed by procedures.
  • Processes should have clearly defined entry and exit criteria.
  • Always include a checkpoint or validation step in a process model. Example process models include Plan-Do-Check-Act (PDCA) and Entry-Task-Validate-Exit (ETVX).
If you have a maxim to contribute please send it to us and we'll share it here (giving you due credit, of course).