Heymans.org » writing http://heymans.org Bert Heymans, Tech Adventurer Tue, 10 Apr 2012 06:30:03 +0000 en hourly 1 http://wordpress.org/?v=3.3.2 Assumptions vs. Dependencies http://heymans.org/2009/01/assumptions-vs-dependencies/?utm_source=rss&utm_medium=rss&utm_campaign=assumptions-vs-dependencies http://heymans.org/2009/01/assumptions-vs-dependencies/#comments Wed, 21 Jan 2009 22:21:49 +0000 Bert http://heymans.org/?p=132 Words have the incredible power to set the trend in a business agreement, nothing new there, but at times differences can get subtle. That’s the case with using “assumptions” vs. using “dependencies”, they can mean the same thing but give a different message in the same context.

There will always be things that are unknown in a projects life cycle. Now, when do you use which word?

  • Filling in those particular blanks is critical for the success of the project? Then go for dependencies, reducing ambiguity on showstoppers is always good.
  • Need to make one choice over another to keep the story in the document intelligent, then you’re safe with assumptions.

Make the right choice, you don't have to guess

Assumptions tend to take care of the unknown but dependencies imply someone will need to take responsibility for them.

It’s a choice that keeps coming back in project charters, proposal texts and product case descriptions.

edit: The thing is that those terms get used as topic headlines a lot in standard PM templates, and sometimes when arguments arise it’s a lot easier to point to dependencies than to assumptions.

]]> http://heymans.org/2009/01/assumptions-vs-dependencies/feed/ 9 Shorter Project Charters http://heymans.org/2009/01/shorter-project-charters/?utm_source=rss&utm_medium=rss&utm_campaign=shorter-project-charters http://heymans.org/2009/01/shorter-project-charters/#comments Mon, 19 Jan 2009 01:17:27 +0000 Bert http://heymans.org/?p=107 A project charter is the document that provides ownership (and authority) to the PM for a project, after someone hands that to you or when you write it up yourself and get it signed, you are the owner of the project on behalf of your company.

The point is, you start out with it and maintain it during the course of the project. I never get project charters handed to me in my current work situation, I always write them myself. And I like them short.

According to what I understand from the PMBOK there are 3 things that are absolutely essential for a good project charter, and those are:

  • a business case
  • the projects constraints
  • the assumptions (or dependencies)

Looking at only those 3 things that’s not much is it? Some of the things I always add are:

  • high level in scope
  • high level out of scope
  • communication plan, list of major project stakeholders with their coordinates and roles
  • general terms and conditions in the mother language of the sponsor, for legal purposes

I made a mindmap exercise in Freemind a long time ago by looking at some example project charters I got my hands on, the combination I came up with looked a bit like this:

berts_project_charter

But that’s too long to maintain if you have a high number of relatively short projects to manage.

Today my actual essentials look more like this:
project charter mindmap conclusion

Here’s the big mindmap:
project charter comparison

project charter comparison PDF downloadpdficon_small

Freemind source file (.mm) freemind_icon

I want to share the whole exercise with you, so here you go, source and everything in a variety of formats.

]]> http://heymans.org/2009/01/shorter-project-charters/feed/ 4