Please Share Feedback

Questions, comments, suggestions? Let us know what you think on our Forum.

To contact us privately, please use our contact form.

Author: Elyse, PMP, CPHIMS
February 11, 2008

As the development of a methodology persists for a PMO, there is a vagueness surrounding the conceptual differences between a project, program, and task. For the project description, simply having a temporary unique endeavor with a beginning and an end is almost too general and simplified. At times, I believe the disconcerting part is that the realization everything is a project comes to light. Projects are large, medium, small, and tiny. As clarification occurs, realization that the manual running of the report every day at 8:30 am really isn't a project, those additions of doctors to the doctor master, really isn't a project. In my experience, the difficulty embracing the concept derives from something deeper.

Organizationally, if you don't know what a project is at this day and age, then here is probably what is occurring in your HIT shop. First, there is no work approval or authorization mechanism for requesting work. Everyone probably has their own lists. Additionally, customization of the environment is spreading like a Californian wildfire sweeping through your ambulatory, clinical, revenue cycle, integration and financial systems. The inpatient billing manager says hey this would be easier and save me some clerk hours. The system analyst says sure, and adds it to her listing. All of a sudden, you have an outside billing interface controlling the system edits in a duplicative manner. Customization spreads. The problem with understanding the concept is not the concept itself. The problem is the realization, that most of the work your department engages in is pet projects for "preferred customers". The work doesn't relate to the strategic value of the organization, and conceptually you are investing your high quality talented resources in penny ante tasks. This is why the simple definition is a double edged sword.

As we struggle with this concept, comments like. "Well my work really isn't a project, it is just a bunch of tasks." Arise. To which my favorite response is, "Okay, well maybe we should group those tasks under a project or program. Can you tell me what benefits these tasks are bringing to fruition?" Afterwards, we continue the learning conversation.

The main purpose of a program is to deliver benefits which will help the organization realize its strategic objectives. Programs are strategy-oriented. Programs have a wide scope, so that the organization can change to meet the benefit expected. As a program begins to deliver the incremental benefits, these deliverables are often accomplished by projects. Obviously, within the project there are tasks to get the project completed and implement the deliverable.

Subscribe and Share!

Did you enjoy this article? Your feedback is very important! I'd like to invite you to keep up to date with the latest posts from Anticlue. We offer several venues. If you have some questions, help can be found here.

1 Comments to “Tasks, Projects, Programs”

First time poster, and I love your blog.

I had another thought on this as well; it seems to me when the IT department does not adequately define roles around a new system going in, or organizational changes around Project Management, etc., then it leads to confusion similar to what you describe above.

I've found the fix is making sure everyone is aware of what PROJECTS are affecting the department, and in addition, how they play a role. This can be done through a tracking board, a project database, or just by forming teams.

Again, I absolutely love your blog, as I see some of the things you talk about everyday.

« IT Value: Is it an Expense Center or a Value Center Quick Little Risk Management Checklist »

Please share your thoughts and suggestions