cazh1: on Business, Information, and Technology

I've been writing about iterative documentation and checklists, and it's easy to see how these are applicable to a number of common IT processes ...

• Build a server
• Apply OS patches
• Move new code into production
• Initiate a project / programming request
  

Unfortunately, there are plenty of other areas in IT that you think should / could have a definable process ... yet there is always some magic to them, a variable recipe that's difficult to capture in a cookbook ... 

• Develop a Business Case: Do you go with hard dollar savings, or soft? Align with a strategic initiative, or do it because it's required to maintain the business? Quantitative or qualitative? Get ownership, requirements and sponsorship from the top down, or bottom up?
• Allocate Project Costs: Should you allocate based on immediate budget benefits, or what you might get in the future? Will you charge to the sponsoring business organization, or the group that will see the benefits (not always the same ...)? And how do you allocate - by user count? Participation? Percent of revenue?
• Create an Effective Project Proposal: Will you describe the As-Is, the To-Be, and lay out a path from here to there? Maybe reverse it - lay out a vision of the future, detail the current state, and give an outline of what must change? Or stick with the basic requirements / objectives / suggested approach?
• Status Reporting and Project Communication: Do you go with a formal written report, a simple email, or word-of-mouth? How high up / low down the chain must you cover? Will "success" be seen as sticking to budget and schedule, or focusing on quality / requirements?   
• Project Management: Agile? Iterative? Waterfall?They all work, but which will work here ...
  
• Business Relationship Management: Will you be most effective with a Numbers focus, or should you work on the Relationships? Are you expected to drive cost savings, or enable revenue? Should you conduct face-to-face meetings on a drop-in basis, or set up a formal schedule with an agenda?

With these IT processes, it's difficult to imagine a checklist or process document that would work (well, I guess I could imagine such a document - but I wouldn't want to write it ...). But there is a way that groups can mimic individual experience, and effectively capture knowledge ... by documenting "case studies", or examples.  
 
It's kind of like common law in the courts, where precedent or authority stems from previous court cases with similar facts. Right and wrong (or, in our case, effective vs. ineffective) is based on what has worked in the past. For example - I've written up a simple outline for a project proposal / charter that provides a framework for capturing everything you might want to know about a potential project. What I haven't published are actual template files we use at work - which at first glance appear quite lengthy and involved, because each section contains examples from previous projects. These "use cases" and sample text effectively capture ideas and approaches that worked in the past, and can be re-used for similar projects in the future.
 
This is one reason why project blogs and wikis can be valuable; many times, new projects appear unique when compared with their contemporaries (haven't we had this conversation before? ...) There's nothing better than dredging up deliverables from past projects and leverage their content to create relevant, experienced-based proposals that will resonate with the business.
 
Note, however, that creating this kind of documentation takes a different thought process. To effectively write  examples, you must genericize where you can, and refer to project specifics as examples. There will always be room for interpretation, but you can and should continue to emphasize the most popular, effective, and/or relevant examples. Alternatives for a given piece of the process could be sorted, for example - like definitions in a dictionary, the most common meaning listed first.  
 
No check boxes here - this knowledge capture is better suited for wiki, not Word. There is still some art in the application of these past cases, but the collected brilliance of past projects will make the task of building a coherent, consistent, effective project (allocation, business plan, etc) that much easier.

Previously ...

• Strategies for Intellectual Property in Consulting Engagements (May 8, 2006)
  
• The Iron Triangle - Quality is a Feature that We Choose to Omit from Projects (October 28, 2006)
  
• What's the Difference between Announcements, Blogs, Discussions, Wikis? (June 26, 2007)
  
• Driving Participation and Contributions on Internal Blogs and Wikis (July 7, 2007)
  
• Alternative KM Tools (2 of 3) (September 11, 2007)
  
• Rules of Golf - Project Prioritization Process Needs Clear Documentation (February 18, 2008)
  
• Optimizing the Wrong Part of Knowledge Management (March 16, 2008)
  

Technorati Tags: best practice, blog, business value of IT, design, documentation, Knowledge Management, PMO, project management, tech management, wiki

Invisible Technorati Tags:
cazh1,
James P. MacLennan,
jpmacl,
MacLennan,