Estimating IT Projects...Waterfall vs. Agile

How do you estimate IT projects?

The number of project estimates depends completely on the project type. Some such as a construction project or IT infrastructure may need only one, two if a change is discovered.  Software development is extremely complex and all assumptions, details, features, and functions will have impact on the estimate.  The more uncertain the requirements the more the risk the project will incur... but that is a different blog. 

Essential PM Skill:  

For all projects whenever there is a change issued, a new estimate should be performed, to determine the impact to the budget and timeline. Every time there is a scope change a new estimate should be performed.

Software Development Life Cycle (SDLC) Estimating

Software development projects are going to require multiple estimates at each of the major phases within each iteration. Software development is especially sensitive to even minute changes and assumptions. 

Traditional Waterfall Estimating

For traditional waterfall SDLC software design and development. In any iteration, we will have

• Sizing Estimate
• Initial Estimate,
• Requirements Estimate,
• Design Estimate,
• Change Control/Scope Change Estimates

Agile Estimating

The Agile SDLC estimation is very different. 

• Initial Story, the whole scope and assumptions.
• Detail Features for each sprint. 
• Change Controls (Scope, assumptions for the overall program)

In a nutshell, the team must determine the scope for each sprint (development iteration).  Changes aren't quoted for each iteration because in Agile, they are added to the whole scope and prioritized perhaps within this sprint, perhaps in another lower priority sprint, down the line.  Although as an Agile PM, you will need to track and report the estimated impact for all changes as well as the impact of the Feature Estimates and Actuals from each sprint to the overall program budget.

My advice for all estimating, don't try to be too sophisticated with any of your estimates, because they are only estimates.  But with the above methods as you achieve each of these milestones or complete each sprint, you know more about what is needed for the program/project. Assumptions will change and that is what change controls and subsequent estimates are for.

Remember, the good PM is always planning and will communicate all changes in timing, budget and scope to the other stakeholders.   It's all in the planning!

For more information on Program and Project Estimating please feel free to contact Trish!  

What do you think?  Please share your thoughts on this.
____________________________________

Armada Business Consulting, Inc.

Need help getting from strategy to execution?  I can help.  For more information contact Trish at trish_sutter@thegoodprojectmanager.com.

Value of Project Closure: Continous Improvement

One of the most over looked and skipped processes in project management is the closure processes of lessons learned and post project review.  Although well documented in the PMBOK,  it is overlooked in practice.  Sure, we obtain sponsor sign off and in turn we sign off on the invoices and pay all the vendors.  But how often do you perform a "lessons learned" let alone a formal "post project review"?

It is all in the planning.  If a project manager does their job well, they can go on vacation when execution starts, because they will have planned the project perfectly.  Everybody will know exactly what needs to be done and will step in and perform on queue.

In the real world, if this was as simple as it seems and everybody knew everything that the project would entail, they wouldn't need project managers.  The reality is, there are a lot of unknowns in projects.  We have to manage those unknowns.   But by using our project management processes we can reduce the project risks and implement continuous improvement.  

Lessons Learned

This is most commonly missed, but I do feel the most important for continuous improvement.  Many organizations skip this because once the project is complete, they don't have the time and are on to the next project.   The value of lessons learned is very valuable for continuous improvement and overall reduction of future project costs.  For those of you familiar with LEAN this is a major LEAN concept.

The PM should go through the project issue log and the change log.  Find the ones that caused problems and what can be done to prevent them in the future.   Be sure to include any lessons in communications, risk planning, assumptions, HR, scope, budgets, quality and timing so you can avoid those issues the next time around. 

Post Project Review

The lessons learned  be fed into the Post Project Review.  The other major component for the post project review should be the metrics.  Is the delivered system or component, performing and delivering as expected?  Is it achieving the ROI?  Is is meeting the metrics that were established in the scope?  This is critical to understanding that the criteria used to justify the project was valid to begin with.  If it isn't, why not?  Does it need to be adjusted for any future projects, more continuous improvement. 

The Post Project Review should be performed as with the initiation process with all the stakeholders and even other project managers so the lessons can be shared. The best lessons I have learned all get fed right back into improving the planning, execution and control processes, with major emphasis on the planning.

Net Net

Use the lessons learned to improve the quality of plans on your future projects.  The better your planning the smoother the project goes.  So the more you can improve the quality of your project plans, the more likely you are to be successful.

What do you think?  Please share your thoughts on this.
____________________________________

Armada Business Consulting, Inc.

Do you or your organization need help with project closure?  Or need help getting from strategy to execution?  I can help.  For more information contact Trish at trish_sutter@thegoodprojectmanager.com.

_____________

The Good Project Manager

In a prior post, I talked about The Project Slayer.  When you terminate a project that has no value.

Today let's talk about common factors for successful projects.  The Good PM.


Many hiring managers love to ask;  "What was your favorite project and why?"

To tell the truth, The Good PM has successfully delivered so many projects, there is not any one favorite.  So instead when I'm asked, I discuss critical factors to my success that applies to all my programs and projects. 

Success is due to good planning, using the PM tools, skills and spending the time on communicating.  Success is also due to hard work with the key team members to get the plan right.  The Good PM goes through all aspects, scope, metrics, timelines, budget, identifying stakeholders, RACI charts, deliverables, sign-offs, communications, vendors, change management, risk management, tollgates, reviews,… and communicates that plan to all the stakeholders. 

On The Good PM's programs and projects, everybody understands what the goals and deliverables are and what they are responsible for.  Once the project is in flight, then The Good PM just takes a weekly status and deals with the project issues.  If there is a major issue or risk that occurs, a Change Control is issued to bring it back under control and this change control is communicated to all, signed off and planned.    

The Good Project Manager does not have failed projects because they use the PM tools and skills to fall back on.  It is the PM’s responsibility to understand the health of their project.  If there is a problem the PM must take measures to correct it and bring the project back to plan. 

_____________________

Armada Business Consulting, Inc.

Need help getting from strategy to execution?  I can help.  For more information contact Trish at trish_sutter@thegoodprojectmanager.com.

How Do You Hire Top Talent?

Top Talent

They say Google is setting the new standards for hiring talent.  Throw away the GPA and the awards as these aren't necessarily predictors of top talent.  Past success on the job is a good indicator, but they are looking for problem solvers, and this part directly correlates to my long time personal hiring preferences.

Qualities

I found the classic interview formats, such as what is your best trait, what is your worst, where do you see yourself in 5 years, just didn't fill-in the information that I needed to make a good hiring decision.  So, I came up with my own criteria and found that criteria has never failed me.  As a hiring manager, I have hired based on three qualities that I specifically seek out in prospective employees.  And my interviews were structured around these three qualities.  With problem solving skills and communications skills having just as high or higher importance than technical skills in some cases. 

• Technical Skills
• Communication Skills
• Problem Solving Skills

Technical Skills

Technical skills can be taught through on-line learning or on-the-job.  Although expertise must be measured in years.  But, having the technical skills is no guarantee that the will be used correctly.  Interview questions are specifically tailored to review the depth of the interviewees technical expertise.     

Communication Skills

Communication skills are inherent.  Either they know how to talk and write clearly or they don't.  You as the interviewer should be able to overcome any cultural impediments to communications, as it does take two for an exchange to occur.  Technical folks are trained how to talk to computers in school, but not how to talk to people.   You as the interviewer need to evaluate the communication skills.  Both written and verbal.  



This is also where cultural fit falls.    If you are in a very structured environment, then someone who is more dynamic and entrepreneurial, may be bored.  Likewise, someone who is change resistant and would not be a good fit in a dynamic ever changing environment.  Again, I structure the interview, to determine the candidates, tolerance for change. 

Problem Solving Skills

This is where the stars and top performers rise to the top.  And I have found that problem solving skills, can only be taught to a degree.  Although the flavor of the month is 6 Sigma for problem solving, which uses a fish diagram, where the participants guess at the cause.  Kepner-Tregoe, walks you through the logical progression of what changed?  I was using Kepner-Tregoe, before I even learned it.  The training allowed me to to give names to the processes I was already using.  

When interviewing, I structure a complex problem in their area of technical expertise.  So for a java programmer, the problem would be java based, for a help desk, it would be PC based, for Systems Admin, Network based,  PM it would be leadership based.  The problems I set up usually has no clear resolution, and basically I look to see how the interviewee, structures the problem solving.  

PMP TIP:  Kepner-Tregoe is great for risk mitigation!   Ask me how sometime.  

___________________________________________

Armada Business Consulting, Inc.

Need help getting from strategy to execution?  I can help.  For more information contact Trish at trish_sutter@thegoodprojectmanager.com.