Search This Blog

Monday, November 30, 2009

Good Project Estimating is an Art and a Science

I have been burned more times than I can count by bad estimates. What can a project manager do to help ensure the accuracy of estimates?  First we should understand the basics behind the estimating process (there are many more than I have listed here). Some items to consider are:

The more unique the project, the more of a challenge it will be to get good estimates

Estimates are only as good as the estimator is at predicting the future

Padded" estimates are not always bad as long as the padding is communicated (... and as long as the Project Manager is the one doing the "padding")

An estimate is not a bid

Estimates using sound estimating practices, performed by experienced estimators from clear specifications should never be negotiated

Ballpark estimates are guesses and should be treated as much by the project team, management, and the project sponsor

Other items to consider when estimating are:

Ensure the statement of work or contract is clear and understood by the person(s) doing the estimates

Ensure that a schedule or mandated date doesn't drive the estimating thought process

Include Risk Management in the estimating process

Ensure that estimates take into account the skill level(s) of the person(s) that will do the work

If your work breakdown structure (WBS) is flawed, your estimates will be inaccurate

Accurate estimating is an art and a science. The estimator (or team) must take into account historical data from past projects, the team's knowledge and experience, the project risks, the statement of work and other project information to make the best estimate possible.

Keep in mind when planning your project that estimates aren't hard and fast numbers. They are guesses, however they should be very good guesses if you have good estimators and are following tried and true estimating practices.

Monday, November 23, 2009

Deming and Project Management

Continuous Improvement is the output of a good Quality Management process, and Continuous Improvement requires the proper application of quality tools and techniques. One of the most recognizable Quality Tools is the "Deming Wheel". The Deming Wheel is a simple diagram that focuses efforts around four processes: PLAN, DO, CHECK, and ACT (PDCA Cycle). While this diagram may seem simplistic at first sight, it is a very powerful tool when applied to projects. In fact, Project Management is dependent upon the PDCA Cycle to deliver effective results.

A quick summary of the PDCA Cycle follows.

Plan is the initial phase of the PDCA Cycle. High levels goals and objectives are agreed upon and resources are acquired. In this phase we are identifying a particular problem or problems and breaking them down into manageable tasks. We want to decide specifically how we will solve the problem and establish metrics to measure progress.

Do is executing the Plan. Also, reporting is done in this phase to check progress. Do can be prototyping in the IT world, designing experiments, constructing a building, building a model, etc.

Check is the evaluation phase. Did we do what we said we were going to do? Did we meet the project's objectives? What does the data tell us? This is where are metrics are analyzed. We are looking at our KPIs (Key Performance Indicators) and making recommendations for action.

Act is the adjustment phase. What are we going to do to get back on track or to make improvements? Should we continue or cancel the project? Do we need to re-plan and start the cycle over again? Here we are acting on our findings from the Check phase. We want to make sure we are acting on the right information at the right time.

The PDCA Cycle is a great tool to help us be successful in Project Management. Using proven Quality Management tools that support Continuous Improvement will help project managers to do a better job managing their projects.

Remember the Four Principles of Quality Management are:

Customer Satisfaction

Plan Do, Check, Act (PDCA) Cycle

Management by Fact

Respect for People

Combining these Quality Principles with your Project Management Processes will lead to powerful results for your customers. 

Thursday, November 19, 2009

Hope and the Project Manager

Hope is important in project management because it helps us keep our commitments, and also helps us put our faith in others . Don’t get me wrong. Hope won’t make you successful; however, hope can guide us to change the unchangeable and gives us courage to do the right things.

Hope gets us ready to fight the good fight. Hope helps us survive the storms that always come. Hope can dispel fear and give us the strength to carry on. To be good project managers (and leaders) we must always realize (and hope) that our best days are ahead of us.

Hope inspires confidence. Hope is contagious. Hope helps us keep commitments.

Thursday, November 12, 2009

Project Status Reports

Click here for article

Project Management Culture

Moving your organization to embrace a “project management culture” takes time and patience. A great first step an organization can take is to ensure that their project leaders are trained and fluent in the discipline of Project Management. Also, and most importantly, senior management must understand and embrace the value of project management, and commit to support the process of implementing project management throughout all levels of the organization.

To help change the organizational culture to one that embraces and values project management, it should fund and support the development of a project office, which can help facilitate rolling out this “project management culture”.

Some first steps that should be taken:

  • Clearly define the roles and responsibilities of existing project managers and project support personnel
  • Develop a basic project management training plan for the entire organization to familiarize all with the project management verbiage and practices
  • Identify and provide specialized advanced training for all project leaders and functional managers
  • Develop a project management office (PMO) to provide enterprise coaching, and to develop and manage your organization’s project management methodology
  • In addition to the methodology, the PMO should develop and maintain standard project management templates for the organization to use
  • Ensure that existing projects are audited and meet your organization’s minimum project management standards
  • Setup a program where your PMO provides coaching to less experienced project managers and oversight of all enterprise projects
  • Ensure all projects have Lessons Learned captured
There are many more things that can be added to the list above, but the intent of this posting was to get people thinking about ways to change the Project Management Culture where they work.

Thursday, November 05, 2009

Theory Z 2.0

Free advice to help you keep your job (or get through life with a smile):
  • Trust and be trustworthy
  • Recognize changing conditions and relationships, and adapt quickly
  • Commit to doing your best in everything you do
Do you have a Theory Z?

Visit and leave a comment. 

Stephen Seay, PMP

Tuesday, November 03, 2009

How to Lead Geeks

Ralph Nader once said, "I start with the premise that the function of leadership is to produce more leaders, not more followers". In the IT world it is hard to produce leaders, and it is doubly hard to produce and keep followers.  

On his blog, Alexander Kjerulf talks about How Not to Lead Geeks and mentions that "the main reason IT people are unhappy at work is bad relations with management". He goes on to say that "the fact is that IT people hate bad management and have even less tolerance for it than most other kinds of employees".

Wow, I couldn't agree more.  I see the mistakes listed below happen every day. I can only wonder how much more productive "geeks" would be if these mistakes weren't repeated on a regular basis.

Here are Alex's thoughts on the top 10 mistakes he has seen managers make when leading geeks:
1) Downplay training
I had a boss once who said that “training is a waste of money, just teach yourself”. That company tanked 2 years later. Training matters, especially in IT, and managers must realize that and budget for it. Sometimes you get the argument that “if I give them training a competitor will hire them away.” That may be true, but the alternative is to only have employees who are too unskilled to work anywhere else.
2) Give no recognition
Since managers may not understand the work geeks do very well, it’s hard for them to recognize and reward a job well done, which hurts motivation. The solution is to work together to define a set of goals that both parties agree on. When these goals are met the geeks are doing a great job.
3) Plan too much overtime
“Let’s wring the most work out of our geeks, they don’t have lives anyway,” seems to the approach of some managers. That’s a huge mistake and overworked geeks burn out or simply quit. In one famous case, a young IT-worker had a stress-induced stroke on the job, was hospitalized, returned to work soon after and promptly had another stroke. This post further examines the myth that long work hours are good for business.
4) Use management-speak
Geeks hate management-speak and see it as superficial and dishonest. Managers shouldn’t learn to speak tech, but they should drop the biz-buzzwords. A manager can say “We need to proactively impact our time-to-market” or simply use english and stick to “We gotta be on time with this project”.
5) Try to be smarter than the geeks
When managers don’t know anything about a technical question, they should simply admit it. Geeks respect them for that, but not for pretending to know. And they will catch it - geeks are smart.
6) Act inconsistently
Geeks have an ingrained sense of fairness, probably related to the fact that in IT, structure and consistency is critical. The documentation can’t say one thing while the code does something else, and similarly, managers can’t say one thing and then do something else.
7) Ignore the geeks
Because managers and geeks are different types of people, managers may end up leaving the geeks alone. This makes leading them difficult, and geeks need good leadership the same as all other personnel groups.
8) Make decisions without consulting them
Geeks usually know the technical side of the business better than the manager, so making a technical decision without consulting them is the biggest mistake a leader can make.
9) Don’t give them tools
A fast computer may cost more money than an older one and it may not be corporate standard, but geeks use computers differently. A slow computer lowers productivity and is a daily annoyance. So is outdated software. Give them the tools they need.
10: Forget that geeks are creative workers
Programming and most IT work is a creative process, not an industrial one. Geeks must constantly come up with solutions to new problems and rarely ever solve the same problem twice. Therefore they need leeway and flexibility. Strict dress codes and too much red tape kill all inovation. They also need creative surroundings to avoid “death by cubicle”.
Making one or more of these 10 mistakes (and I’ve seen managers who make all 10) has serious consequences, including:
Low motivation
, high employee turnover, 
increased absenteeism, 
lower productivity, 
lower quality
, and bad customer service
Happy geeks are productive geeks!