Posted by maria bodkin on Sep 5, 2013 in blog
This blog is the third in the series “Why Projects Fail” and aptly named “Underestimating Project Work”. Let’s get directly down on managing the risk of underestimating the work. The consequences of underestimating project work can be evidenced a bit too late in the Planning or Execution phase At this point there’s not much a project manager can do to save the project, but this blog attempts to provide some work-arounds. How you, the Project Manager reacts to underestimation can definitely help to ensure project success and minimize customer dissatisfaction. How we present this necessary change in scope goes along way toward goodwill with the customer. What leads to under-estimation? There are a few factors: 1) Sales and the Client When I began my career as a software engineer for a systems integrator, I was stymied when Account Managers would provide estimates to the client for custom software development when they never wrote a line of code in their life. Often we software engineers would work long hours and weekends to produce the customization on time. We were also PO’d when sales people made statements that the base product has X functionality when, in fact, it did not. We call that vaporware. And, of course it was the development team leader (and sometimes the developers) who had to break the news to the client. Unfortunately the Development Team was never part of the sales or account management process. As a project manager in the second half of my career, nothing much has changed. Although my situations were usually external client based, the story is same for internally based clients. On most of my projects, the client/executive sponsor already had a timeline in mind regardless of the scope. Of course it’s up to the Project Manager to agree to exactly to what can be done in the given time frame. (See Issue 2 for suggestions for controlling scope). Further, the given estimates are usually based on a one liner scope statement. All I can say at the moment is what a shame when the Project Manager is not involved in determining the initial estimates. Today as I am running my own business under-estimating how long a project will take you lead one to charge less than you deserve for all the time you put in. This isn’t good for your morale or your bottom line. The common denominator is that all of these affect the project unfavorably and lengthen the timeline for the project, run over budget and decrease client satisfaction. I’ve sat in the room with the client at the earliest stages of the project and explained these limitations to the customer. Then I hear “that’s not what Sales/Account Management told us” I scratch my head, but the bottom line is you’ve hit a wall with the client and it’s hard to recover from. They may be frustrated with...
Read More »
Posted by maria bodkin on Jun 13, 2013 in blog
The number one cause of project schedule and cost overruns are scope changes PMI certified and experienced project managers realize that cost, schedule and scope (the Triple Constraint) are critical factors for a successful project. For a successful project, the PM must effectively control scope for the proper balance of the Triple Constraint. The role of a Project Manager is to show the impact of scope changes on the project’s cost and schedule and to create a balance between them. Scope control assures all requested changes and recommended corrective actions are processed through the project’s Integrated Change Control process. Project scope control is also used to manage the actual changes when they occur and is integrated with the other control processes. Uncontrolled changes are often referred to as scope creep. Change is unavoidable but it requires a formal change control process. There will be occasions when requested changes have to be made to comply with policy changes, legal regulations, changes in the business direction of the organization, or where technology may require change. Non-essential changes can be avoided, however, through an effective formal change control process. Scope Creep Strategies Here are a few pro-active strategies to reduce the likelihood of schedule or budget overruns caused by scope creep: 1. Set clear expectations of the entire community of stakeholders during the Kick-Off meeting Ensure your client knows that the project has to be completed at a certain level of quality, in a certain amount of time and at a particular price to make the project successful. If the project has a schedule constraint, you may need to look into increasing the resources assigned to the project, or have the quality/scope reduced. 2. Recognize all stakeholders Most importantly include level 1 stakeholders, i.e., department heads and sponsor, and include them in defining the scope baseline as well as requirements specs. Establishing the scope baseline means describing the product (business functional requirements) in detail early. The scope should also detail what is not in scope. The requirements specifications define the product to the level of detail that allows all project groups to perform their activities productively. When the product is properly defined the project manager and team members know “what is in and what is out of the project scope”. 3. Gain formal agreement from the project sponsor and other “approvers” Getting approval on the detailed scope statement and publish the scope baseline. Get the agreement from the right people, or organizations, on the business and functional requirements of the product being built. All groups dependent on complete and accurate product specifications must approve the document to ensure that it meets their needs. When the product being built meets the needs of the users fewer changes need to be made. I like to have the vision, project objectives and scope baseline displayed on large posters in the “war room” so that the...
Read More »
Posted by maria bodkin on Apr 11, 2013 in blog
How does one know when and why a project has failed ? This is the first issue in a series of Why IT Projects Fail & What We Can Do to Reduce the Risks. If you are an experienced project manager like myself, you’ve been on or led projects that have failed. Com’on every project manager has had at least one failed project under their belt to some degree. First, let me ask a question if I may. How does one know when and why a project has failed ? Here’s the best definition I’ve found: A project is considered a failure when it has not delivered what was required, in line with expectations. A project must deliver to cost, to quality, and on time; and it must deliver the benefits presented in the business case. This initial issue in the series will provide an overview of reasons Why Projects Fail. Later blogs will focus on the details behind each reason for failure and provide suggestions on either eliminating or reducing the risk. This is in no way an exhaustive list of reasons for project failure. This is where you, the reader, come in. I encourage you to post more reasons or even debate the failure risks in this blog. Ready? Ok, Here we go: 1) Balancing the Triple Constraint PMI Certified and experienced project managers realize that cost, schedule and scope (the Triple Constraint) are not the only critical factors for a successful project. Stakeholder and Quality management are now seen as an extension of the triple constraint. 2) Unrealistic estimates When it comes to underestimating the required resources, requirements gathering may be the issue. Typically in software development projects, I ask technical team members to provide the detailed estimates for the activities and tasks for which they are responsible. I’ve found that developers (I was one early in my career) can be too optimistic in estimating complex requirements. On the other hand, there maybe a person who overestimates. Call it ego, trying to save the organization money or buying time, it happens and it’s a problem. In a consulting or commercial service environment, sales people sometimes underestimate resource requirements or project timelines in order to win an account or project. 3) Lack of dependencies created during project initiation I’ve often seen contractors and sub-contractors begin design and development for their piece of a project only to find they have to revisit both due to other dependent items that must be completed prior to the contractor’s design and development effort. Even if no technical dependencies are established, the contractors cannot start testing until other pieces of the puzzle are completed. This results in either unnecessary time spent (=$) by the contractor or added costs to the client, not to mention delays to the project. 4) Objectives stated in technical terms, rather on the business benefits Technology team members should not...
Read More »
Posted by maria bodkin on Jan 30, 2013 in blog
Lookout for the upcoming blogs from Bala Information Technology Solutions. We’re starting the first in the series titled “Why Project Fail”. Check back at the end of this week!
Read More »
