Healthcare Business Development

Bear with us…this is just a Technorati post.

Technorati Profile

The title here is just a metaphor for documenting your path and making it accessible to others who will follow you.

In the course of getting this blog up and running, I encountered various problems with system administrative actions that would not respond. System re-installs, patching, etc. did not help. Various Google searches - and I am pretty good with Google - discovered several people who had similar or identical problems, but the discussion threads trailed off into nothingness. I finally found and fixed the problem, which had to do with a configuration setting.

And then, thinking of others who would travel the same path in the future, I updated one of the discussion threads I found through the Google search. (For those who are interested,  go here.)

How much time could you save others in your company by documenting and disseminating the answers to problems you have solved? Better yet, how much time will you save yourself in the future when you encounter the same problem, yet cannot quite remember the particulars of the solution?

This reminds me of one of the phrases I use in our project management class. “Lessons learned usually aren’t.” The point being that many people beat the dead horse about what went wrong, but never take the next steps to deconstruct the problem, define actions to fix it, and execute them.

Help somebody else. Help yourself. Write it down and make it available.

Thinking about this reminds me of the narrow-minded counterargument: “well, if I tell her, then she will know the answer, and then she will be ranked the same as me, and paid more, etc.” More on that later.

“Information Design” is a much-maligned term. It usually refers to the process of organizing and delivering information in a way that is easily used. Many things can benefit from good information design: wayfinding, document design, web design, and so on.

When you are creating a proposal, you want to do it in a way that maximizes your chance of winning. Good information design can contribute to that goal by simplifying the evaluator’s job - making it easy for the evaluator to find and grasp the information you present.

I usually consider a pragmatic approach to information design for documents; one that focuses on four elements:

1. Syntax. This defines the ordering and relationship between different information elements. Usually expressed as a hierarchy within any individual document, but the nature of hypertext documents means that a complex web can exist.
2. Semantics. This defines the meaning of each information element within the document.
3. Style. This defines any stylistic constraints or rules that you want to apply to the information.
4. Presentation. This defines the way the information elements looks graphically.

What you do with these elements is driven by the answers to two questions:

1. Who is in your audience?
2. What do you want them to do with the information?

Armed with this information, you can begin the design process. In a series of future posts, I will explain more about the four elements and the two questions, then outline a procedure for creating an information design. Once you are finished, you can use that design for a series of documents of the same type. And if the design is good - and your proposal adheres to the design rules - then you improve the chances that evaluators will understand your story. (Whether it’s a good enough story to win is a topic for another post.)

I’ve just been looking at a couple different schedules in Microsoft Project. One was in the course of doing some evaluation for a nonprofit organization, the other was submitted in the course of a client project. Unfortunately, neither really qualified as a project schedule.

Both documents - done in Microsoft Excel - succumbed to the mistake of making a requirements checklist into a schedule. While it’s important to identify requirements, and important to verify that they were satisfied in the course of the project, requirements do not represent scheduled activities per se.

Imagine something like this (yes, I’m overworking the standard project management “building a house” analogy again):

• Slab concrete foundation
• 2 x 6 construction
• Glass fiber insulation
• 200W electrical service
• 75′ setback from front property line
• Built-in microwave oven
• 2 1/2 bath

etc. ad nauseaum.

But the above is just a list of specifications (albeit incomplete) for the house. Instead, we want to think of major structure components of a project, then the activities that people have to perform to complete them. For example:

• Foundation
• Survey
  • Excavation
  • Set forms
  • Pour concrete
  • Remove forms
  • Backfill
• Framing
  • Set sole plates
  • Frame walls
  • Install wall sections
  • Install rafters
• Etc.

(Of course, I have omitted many elements there - including the critical one of completing a design and obtaining a building permit!)

At various points in the process, there may be an activity checkpoint that validates the activities completed against the original specifications. That is the function of the previous list - to define the performance expectations for the finished result.

But that is not the same thing as a work breakdown structure and schedule.

There is one more side effect of trying to do scheduling in Microsoft Excel. Most such schedules simply ignore that there might be any dependencies between activities. And that can get you into a lot of trouble, very quickly. “Sure, we can complete that in three weeks!”

Granted, you have to explicitly indicate such dependencies in Microsoft Project (or your other real critical path method (CPM) scheduling tool of choice) but at least the tool will tell you what the overall schdule will be with those dependencies.