Google Paparazzi
Permalink Comments off
Ok, so I’ve gone a bit crazy with my knitting/yarn addiction in the last year. You can check the rest of my crazy on FB or my dedicated blog. James added a link to it in the side bar next to our gallery link.
Here is just a taste of my crazy that I started last night for the Knitting Olympics in honor or the winter Olympics that started yesterday. GO KNITTERS!!! Ahem, see what all this “fiber” has done to me? Oh, and did I mention the soooo yummy strawberries from James. He is definitely the best!
Permalink Comments off
You can add your name here: http://charterforcompassion.org/
Permalink Comments off
I think all product charters should replace the word “scope” with the word “expectations.” This is a better description for what’s being captured, is more adaptable during the project and is less hostile.
I usually see the scope section of a project charter used in one of three ways.
Often the scope is used to detail a preliminary design for a product. This is just silly. The project team is going to recreate the design many times over the life of the project. Trying to nail down and agree on something that you know in advance is wrong is a waste of time.
Another common use of scope is to list the features that the client expects the project to provide. If the project charter already includes a Vision or Objectives section, this is also a waste of time. How many times do you need to restate the same thing?
The last common use, and the one I really despise, is a defensive mechanism to list things that are too expensive or time consuming to include. This often includes ancillary features that will be costly to develop and support/development tasks that the team wants someone else to provide. Don’t get me wrong, the project charter needs to include this information, but not as “scope.” Categorizing this as scope means two things: it’s hard to change later when you realize you were wrong (you found a cheaper way to deliver an out-of-scope feature) and it turns a team-building opportunity into an adversarial, us vs. them conversation.
When I’m building a project charter, I don’t want to talk about what’s in and out of scope. I want to talk about the vision for the product, what it might to cost to get there, and most importantly: what’s going to be the best bang for the buck. Expectations fit nicely into this conversation.
We could be wrong. We can’t predict the future. But here’s what we expect.
Permalink Comments off