Empirical or Definitive

Ever heard of the cone of uncertainty?  The cone shows the historical error at certain time periods in a tropical cyclone forecast.  What happens today and what has happened in the past is pretty much all we know.  We can certainly use all kinds of scientifically proven processes or models to try to predict the future.  But, in the end, we won't know what tomorrow will bring until tomorrow.  If you are dealing with machines, you should be able to predict upcoming events with relative certainty.  If you are dealing with people or something like mother nature, the odds of predicting events with certainty are slim to none. We need to assume that baselines may change significantly during a project or in life.  In unpredictable environments, empirical methods should be used to monitor progress and direct change, rather than using definitive methods to try and predict progress and stop change.

Definitive

You work and work and work, trying to lock in your scope, your schedule, and your budget before the project even begins.  You do everything you can to lay it all out, attempting to account for every possible variable.  Unfortunately, you don’t know what tomorrow will bring.  So, the further out the schedule goes, the greater the risk something is going to change.  What’s it going to be?  Is scope going to change or maybe the schedule will slip?  With the cone of uncertainty, whatever foreseen changes are ahead, there are going to be exponentially more unforeseen the further out the schedule goes.

Empirical

In reality, you begin with the greatest unknown.  Even some of the unknowns aren't even known.  Just accept it!  You’re not the Amazing Kreskin.  You can’t predict the future.  The only thing that is guaranteed is something is going to change.  So, plan for that change.  Know the goal you’re trying to reach.  Keep your eye on that goal.  Now, do what you do.  Develop, lead, manage… it doesn’t matter.  What does matter is you see where you are right now, know where you want to go, and then at a measured time, see where you are again.  Make some adjustments and repeat.  You will find if you just accept the change, you can use it to your advantage to get closer and closer to your goal.

Summary

You can not predict the future, only plan for it.  You can not steer a hurricane, only plan for it.  You can not prevent change…  Can you guess what comes next?  That’s right, you plan for it.

My Merge of GTD and Kanban

I'm not going sit here an boast of being some kind of expert on Kanban or guru of personal productivity.  I'm just a Project Manager/Leader who is always keeping his eyes and ears open for newer or better ways to manage time or work.  I believe you should always try to eliminate non-value-added processes, resulting in a positive impact of customer satisfaction, while reducing support costs.  How do you do that?  You get it done as effectively and efficiently as possible. I recently completed Getting Things Done by David Allen.  It was an interesting book.  Though I use paperless processes to "get things done", David offered one bit of advice that resonated with me.  To advance a task or activity to more of an actionable conclusion, he said to ask "What's the next action?"

This parallels what I do with my Kanban (task) board.  I currently have 4 columns:  Backlog, Work In Progress (WIP), Blocked, Done.  When a prioritized task can not be worked, I put the task card (user story) in the "blocked" column.  I then ask myself the question.  What's the next action? Without asking yourself that simple question, your task may be blocked longer than necessary.  You have to understand there may be 3 or 4 steps you need to complete before you can unblock your task and get it back to WIP.  So, ask the question.

As to not ignore the obvious, I recommend you write your tasks in a standard user story format.As a [perspective], I want to [activity], so I can [desired outcome]

It doesn't matter if you use a physical or virtual Kanban (task) board.  I recommend following 3 simple rules:

1. Keep your tasks visible

2. Keep your tasks limited

3. Keep your tasks actionable

Meeting Acceptance Criteria Implies Customer Satisfaction

checklist

It doesn't matter if your model is Kanban, Agile, Waterfall, or RUP.  You can't close out a project or task without first identifying the Acceptance Criteria.  Acceptance criteria begins to take shape during the first moments of a project or task. If you are utilizing Kanban or Agile, everything pertaining to your deliverable should be captured on your story cards.  This includes story details and acceptance (testing) criteria.  Satisfying all acceptance criteria implies the needs of the customer have been met.

If you following Waterfall, RUP, or similar model, you would expect to identify acceptance criteria, along with scope description and project deliverables, in the project scope statement.  (These are each components of a scope baseline)

It all goes back to requirements and stakeholders' satisfaction.  Remember each requirement should add business value by linking to a business or project objective(s).

Those criteria, including performance requirements and essential conditions, must be met before project deliverables are accepted. Regardless of your model, spare yourself a lot of wasted time AND money by documenting acceptance criteria early.

If You've Never Failed...You've Never Lived...

If you have ever been on the fence about doing something, out of fear of failing, this video will give you the push you need.

• Create that new service or product
• Go for that promotion
• Get that new job
• Launch that company

Life = Risk

Free Project Charter Template

Project Charter Template

How many times have you started working on a project and don't even have formal authorization for that project to exist?  A project charter is a document issued by the project initiator or sponsor that formally authorizes the existence of the project, and provides the project manager with the authority to apply organizational resources to project activities.  Using this template will put all the cards on the table.  Knowing answers to key areas before you begin will save you time and money. This document includes areas for project overview, authority and milestones, organization, and points of contact.

On your current project, do you know the project oversight authority?  Do you know your critical success factors? Have you documented all of your project roles and responsibilities?  If you used this template, you would increase your chances for success by documenting the basics up front.

MS Word

[Click here to download the free Project Charter Template]

Free Project Initiation Worksheet

Project Initiation Worksheet

When you are about to initiate a new project, you should capture the basics of project information.  If you don't, you're walking into a minefield.  Even before you write up a charter, you should be able to answer the following: Problem (or Opportunity) Statement -Describe the business reason(s) for initiating the project, specifically stating the key business problem or opportunity

Project Description - Describe the approach the project will use to address the business problem

Project Goals and Objectives - Describe the business goals and objectives of the project. Refine the goals and objectives stated in the Business Case (which you should also have)

Project Scope (Requirements) - Describe the project scope. The scope defines project limits and identifies the products and/or services delivered by the project. The scope establishes the boundaries of the project and should describe products and/or services that are outside of the project scope.

Critical Success Factors -Describe the factors or characteristics that are deemed critical to the success of a project, such that, in their absence the project will fail.

Assumptions - Describe any project assumptions related to business, technology, resources, scope, expectations, or schedules.

Constraints - Describe any project constraints being imposed in areas such as schedule, budget, resources, products to be reused, technology to be employed, products to be acquired, and interfaces to other products. List the project constraints based on the current knowledge today.

If you can articulate these seven areas, you've proven you have at least a basic understanding of what you're up against.  If you can not, you better go back and find the answers.  It is a lot cheaper to answer a question when the project is still initiating, compared to deep in executing.

[Click here to download a free Project Initiation Worksheet]