The Project Coach

For those of my PMP friends and colleagues who are firmly immersed in the waterfall way of doing things but who are hearing more and more about agile and scrum and wondering what all the fuss is about, I thought it might be a good idea to write a series of articles comparing and contrasting the two approaches.  I’d like to start by stating that I am very much a fan of agile and scrum and believe that the traditional PMI methodology, when practiced in a sensible manner and the agile scrum approach have more in common than you would think. At the end of the day the purpose of both is the same – to get work done well.  › Continue reading…

In her blog last week , Cindy Vandersleen talked about the challenges of gathering requirements and how the devil is always in the details.  I think many people would agree with this assessment; I know I do.  My best practice for gathering a comprehensive set of project requirements is to build a Requirements Template, and this week I’d like to share with you some tips for creating a model that your organization can use again and again to collect a comprehensive set of requirements and manage scope creep from the word “GO”.  › Continue reading…

In my last article on estimation, I talked about creating consistent estimates by establishing a scale, where for every type of work you do, and for a range of complexity levels (i.e. low – medium – high), you record pre-set values that can be plugged in to your estimates.  What I was in fact describing was a complexity model.  In this article I will describe how as a team you can build your own complexity model for your development organization to govern your estimates. › Continue reading…

In my last article, “Is it bigger than a breadbox”, I talked about the three points in a project when estimates are usually delivered.  The topic of that article was the rough order of magnitude (or ROM) estimates generally given during the project selection process or at project initiation.  Those estimates can have +- 50% margin of error in them due to lack of information.  Once the project is approved, the team begins working on scope definition artifacts, developing first a high level, then a detailed scope statement, and a work breakdown structure to establish a scope baseline.  What I want to discuss in this article is a method to derive a planning estimate at a point where the high level scope statement is created, but before the detailed scope definition or WBS artifacts are finalized. › Continue reading…

One of the most perplexing dilemmas of any project portfolio process, a catch 22 really, is how to estimate the size of the potential candidates being submitted before the selection board.  The catch 22 is that the selection committee wants an estimate of how much the project will cost before they can make a decision on whether to approve of it.  However, no work has been done on the project yet to define the scope or requirements to know what work would be necessary.  In fact the team that could even do the estimating has not yet been assembled.  No one wants to even invest the time to do any discovery until they understand the overall cost of the project.  So, if you are a program manager, you argue, it is impossible to determine a reasonable cost.  The decision makers counter-argue that they cannot make a decision without some kind of budgetary number to consider.  So you assemble a technical team and ask them to give you some kind of ballpark estimate based on the very sketchy facts you have at such an early point in the project.  They of course protest, suspicious that they will be held to the number when requirements balloon later in the project.  And round and round you go … › Continue reading…