Posted by maria bodkin on Mar 23, 2014 in blog
The best project managers are those who consistently deliver, on time and within budget, projects that meet or exceed stakeholders’ expectations This is no surprise. This, of course is a given and doing so is merely meeting expectations. If you want a Super Project Manager that can exceed expectations, you will have a number of attributes listed here. Nonetheless these characteristics do not help you choose the right project manager but rather guide you through the process. In my humble opinion the top skill for a project manager is effective communication. Communication What is effective communication for a PM? Successful project managers effectively use e-mail, meetings and status reports to communicate their ideas, get decisions made and resolve problems. They also understand that they need to discuss their project in the context of whatever is most important to their audience. Communication skills are an essential competence required in almost all jobs today. The project manager should be able to demonstrate that they have the experience to communicate clearly whether speaking or writing. When interviewing PMs to determine if they have effective communication skills it’s essential to ask for specific stories in their work history of how they interacted and influenced others. A common job interview mistake is to think that how you communicate in the interview itself will be enough to demonstrate your ability to communicate. It isn’t! The candidate should draw on their work experiences and come up with at least two examples contrasting to show the depth of their communication skills. Again, simply telling you what mediums they use to communicate will not suffice. Without asking directly they must show how they interacted and influenced others during critical times on a project. It should also go without saying that all answers should follow the STAR method. I suggest cutting the interview short if the candidate does not follow this method. The STAR system is a highly recommended as a way of responding to structured interview questions common in competency based interviews. Describe the Situation you were in Outline the Task that was involved Describe the Action you took (remember to use ‘I did this’ rather than ‘we’) Explain the Result Leadership Since many project team members don’t usually report directly to the project manager, the project manager has to find ways to motivate team members over whom they have no direct influence and who can make or break a project. Project managers also need to be able to inspire the confidence of stakeholders and sponsors in the event the budget or timeline needs to be renegotiated or additional resources are needed to complete the project. Asking for experiences in how the candidate encouraged and motivated the team are clear examples of leadership Here a few high impact leadership-related questions. Again, notice if the candidate provides an example of project management history in a structured manner. Tell me...
Read More »
Posted by maria bodkin on Jan 13, 2014 in blog
Bridging the gap between IT and business will solve many of the problems on IT Projects Technology team members should not work in isolation. Remember, the IT solution is owned by the business in which it benefits. According to the Project Management Institute there are several reasons to initiate a project: Market Demand Business Need Customer Request Technological Advance Legal Requirement Social Need For each of the above reasons to initiate a project, all serve to benefit business. Even a Technological Advance benefits at least one businesses in the organization. So, doesn’t it make sense that the business need be front and center in the project objectives? For many seasoned Project Managers this is a no-brainer. Nonetheless may terrific software developers get promoted to Project Manager and focus on the technical rather than the business needs. Starting a project without clear objectives, and a prepared plan of action immediately sets the project up for failure We create the project objectives when we create the Project Charter. Your business suffers when you try to implement a plan without clarity and forethought. You can define the scope of the technical and organizational components of the project, how many resources you’re willing to allocate to the entire project, establish clear deadlines and the expected results. While one cannot predict the final outcome of the project, certain measures can be implemented against stating project objectives in technical rather business needs and of course the ultimate risk of project failure. There are several ways to write project objectives to minimize the risk of project failure. As a matter of fact this blog’s purpose is to provide best practices, in creating project objectives to minimize this dreadful risk. Here are five practices in creating effective project objectives based on the needs of the business: 1) Align Project Objectives with Business Unit and Corporate Objectives It’s important to initiate projects with objectives that align with the organization’s business objectives. Projects can help you establish your place in the market, increase business, or improve your business reputation. Even with a project plan in place, there are various reasons that can contribute to your project failing to meet your business objectives. Careful planning can help avoid these pitfalls. Companies develop their business objectives based on the goals they set forth for the quarter or year. A best practice is for the business units to align their objectives with that of the business as a whole. If objectives are unclear, it could leave a business to initiate projects that don’t accomplish the company’s objectives. Objective alignment is a powerful project management technique that not only validates the reason for the project but also demonstrates to the team their ongoing value to the business and organization. When you engage project teams with their work through objective alignment, they become committed to the project and achieve higher levels of individual performance....
Read More »
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 »
