Tag: Methodologies

Make Confident Estimates in 5 Steps

Written by William Davis on November 19, 2015. Posted in Articles. 12 Comments on Make Confident Estimates in 5 Steps

Do you sometimes have difficulty making project-related estimates? When you do make an estimate about about an uncertain, future outcome, how confident are you in your estimate?

How confident do you want to be?

Making estimates about uncertain, future outcomes is something every project manager does regularly. Sometimes, owing to our experience and knowledge, making those estimates is easy. But other times, creating an estimate is difficult to do. Even after we make an estimate, we may not feel confident about that estimate.

Here’s a new estimation technique to use when you’re faced with estimating an uncertain outcome: Statistical PERT. Statistical PERT is an easy, five-step technique that uses Microsoft Excel to create probabilistic estimates for bell-shaped uncertainties. (A bell-shaped uncertainty is one where there is an improbable minimum value, and equally improbable maximum value, and a most likely outcome that lies somewhere towards the middle between those two extremes).

You already know PERT: the Program Evaluation Review Technique. PERT estimation using the PERT formula has been around for decades, even before the birth of personal computers. The PERT formula is:

Optimistic+4(Most Likely)+Pessimistic)/6

What does the PERT formula calculate? It returns the arithmetic average for a bell-shaped curve that is implied by an estimator’s three-point estimate. With PERT, one-half of the expected outcomes for an uncertainty should exceed a PERT estimate, meaning a PERT estimate is no greater than 50% reliable. Do you want to estimate project tasks and be wrong half the time? I don’t!

Some people manipulate the PERT formula to place greater weight on the pessimistic outcome, but it’s an arbitrary manipulation of the PERT formula. Isn’t there a better, easier, more flexible way to obtain probabilistic estimates?

Yes, there is! Using two, built-in statistical functions that come standard with Microsoft Excel, Statistical PERT lets anyone create probabilistic estimates using a simple, five-step process. Even better, Statistical PERT lets estimators use their own, subjective opinion about the most likely outcome to influence those probabilistic estimates.
Let’s examine the five steps of Statistical PERT.

Step 1: Make a three-point estimate. This is no different than making a PERT three-point estimate. Choose minimum and maximum values that represent implausible, extreme values for the uncertainty you are estimating. Then, choose a most likely outcome you think best represents what will actually happen in the future. The most likely outcome should be somewhere towards the middle of the range.

Step 2: Use the PERT formula to estimate the mean. The statistical mean is the arithmetic average of all possible outcomes for the uncertainty you’re estimating. The PERT formula estimates the mean.

Step 3: Render a subjective opinion about how likely the most likely outcome really is. With Statistical PERT, you can choose between six different opinions:

Nearly certain
High confidence
Medium-high confidence
Medium-low confidence
Low confidence
Guesstimate

Step 4: Create a SPERT standard deviation using the SPERT-7 Rule. Each of the subjective opinions in Step 3 corresponds to a ratio scale multiplier that is used in Step 4’s SPERT standard deviation formula. The correspondence looks like this:

7% (nearly certain)
14% (high confidence)
21% (medium-high confidence)
28% (medium-low confidence)
35% (low confidence)
42% (guesstimate)

The SPERT standard deviation formula is easy:

SPERT Standard Deviation=(Maximum-Minimum) × Ratio Scale Multiplier

Step 5: Use NORM.DIST and/or NORM.INV to create probabilistic estimates in Microsoft Excel. With the PERT-estimated mean and the SPERT-estimated standard deviation, you now use two statistical functions for the normal probability distribution in Microsoft Excel 2010 or later. The NORM.DIST function (normal distribution) finds the cumulative probability of any value between the minimum point-estimate and the maximum point-estimate. The NORM.INV function (normal inverse) finds the precise point between the minimum and maximum point-estimates that matches any probability you choose between 0% and 100%.

Here’s a Statistical PERT example. Suppose I want to create a planning estimate for a project task that I think will most likely take 60 hours to complete, but it could take as little as 40 hours or as many as 100 hours.

Step 1: Make a three-point estimate. My three-point estimate is {40, 60, 100}. As long as the minimum and maximum point-estimates are improbable and possible, and the most likely point-estimate is somewhere near the middle of the range, I can use Statistical PERT.

Step 2: Use the PERT formula to find the mean.

PERT Estimated Mean= (40+4(60)+100)/6= 380/6=63.333 hours

Step 3: Render a subjective opinion about how likely the most likely outcome really is. I’ll say that I have “Medium-high” confidence in the most likely outcome of 60 hours.

Step 4: Create a SPERT standard deviation using the SPERT-7 Rule. The SPERT-7 Rule equates “Medium-high confidence” to a ratio scale multiplier of 21%. Now I can find the SPERT standard deviation:

SPERT Standard Deviation=(100-40)×21%=12.6 hours

Step 5: Use NORM.DIST and/or NORM.INV to create probabilistic estimates in Microsoft Excel. We’ll use NORM.INV to find a SPERT estimate that has 80% confidence. Put another way, I want an estimate where there is only a 20% risk that the actual outcome will exceed my SPERT planning estimate.

NORM.INV requires three arguments: probability, mean, and standard deviation. The preceding steps obtained all that information, so, in Excel, I just plug-in the values into the NORM.INV function:

NORM.INV(0.80,63.333,12.6)=73.9 hours

That’s it! My SPERT estimate with 80% confidence is 74 hours. So, there is an 80% probability that the actual outcome for my project task will be equal to or less than 74 hours; there is a 20% risk that the actual outcome will exceed 74 hours.

Using Statistical PERT is easy to do. Try using Statistical PERT the next time you’re faced with estimating a difficult, bell-shaped uncertainty on your next project! Statistical PERT makes it easy to confidently estimate any bell-shaped uncertainty.

A PM’s Guide to Use Cases Part 2 – : Use Case Diagrams Explained

Written by Elizabeth Larson on November 10, 2015. Posted in Articles. 16 Comments on A PM’s Guide to Use Cases Part 2 – : Use Case Diagrams Explained

As promised, this is the third article in our modeling series and the second one on use cases. We had promised that in future articles we would show examples of use case diagrams, explain how to build them, and describe why we should create use case narratives. And yes, we’ll explain how use cases provide the same information as the Given—When–Then format. So here we go!

Summary of previous article

Use cases help our projects in two very different ways. Use case diagrams are immeasurably helpful in understanding scope and the use case narrative is invaluable for getting the detail needed to build the product or service. Although used primarily in software development, use cases are also helpful when creating processes and developing equipment. They work wherever there is interaction between people and what those people need to do.

Use case diagrams are one of several techniques we use to help with both the project and product scope. We find that the use case diagram structures our thinking and helps us remember functionality we might otherwise have forgotten.

In the last article we said we would explain the terms reference in this example use case diagram.

Figure 1 – Use Case Example

Summary of Five Key Terms

In use case diagram example above, there are terms labeled with five numbers. Each one of these numbers represents five questions, the answers to which help us understand requirements, as well as create use cases.

What is our solution? Usually, projects begin with a business need (problem or opportunity) to be addressed, and that need is addressed by a solution. In the world of use cases, this solution becomes our system, and it contains all the work we want to do on the project related to the end product. In other words, the “system” on the use case diagram represents the product scope. In our example, the scope of the banking system includes features and functions that we want to include as part of the solution scope. Let’s keep in mind that the scope of the project is directly related to the scope of the product, so the more complex the solution, the larger the project scope.
Which stakeholders will interact with our system? Using use case lingo, the stakeholders using the system are designated as actors on our diagram. Actors are always outside the system but always interact directly with the system. They can initiate a use case, provide input to it, and/or receive outputs from it. Actor to actor interaction is not described by use cases and can be thought of as business processes, not use cases.
What other systems interact with our system? These are also actors since Actors can be people, other systems, time triggers, or event triggers. Actors, again, whether they are people or other systems, for example, can provide input to our system and receive outputs from the system. For example, a process is kicked off at a particular time, like month-end, it is a time actor. If it is triggered by an outside event, such as the outside temperature causing a change in the thermostat, it is an event actor.
How do these stakeholders want to use the system? These are our use cases, which describe how actors want to use the system. Use cases are high-level processes and are shown on the use case diagram as a process name surrounded by an oval shape. The use case name describes the process at a very high level. In our example diagram, we know that customers and internal banking stakeholders want to have the functionality to perform banking transactions. But unless we examine the steps involved in these processes, we will not be able to understand the real requirements related to the desired functionality. That is, we can see the birds-eye view of the functionality needed, but we will know nothing about each process itself. That is why use case diagrams ae wonderful for an understanding of product scope, but do not provide the detail we need to build the requested features.
Interfaces. The lines between actors and use cases, sometimes known as associations, allow actors to talk to the system and the system to talk back to the actors. For software, these represent user interfaces. User interfaces are screens used to allow data to be both input and displayed. The use case diagram, by showing these interfaces, provides a nice picture of work that needs to be done, since each line, or interface, means a screen or series of screens that needs to be built. Notice that the lines do not have any arrow tips. Interfaces do no show whether the data is input (comes from the actor) or is displayed (comes from the system). Arrows denote dependent relationships, which we will discuss in a future article.

Naming the actors and use cases

Actors. As obvious as it sounds, the user role or function, and not names of individuals are preferred for the actors in the use case. For example, use “Accounting” instead of “Erik.” Although we know that we should not use names, we sometimes forget because everyone knows “Erik.” But what happens after “Erik” has left the organization? Not everyone will remember what his function was.

Use Cases. Remember that use cases are processes. Accordingly we name our use cases as we would any other process, with a strong verb and a noun, that is, an action and an object of the action. Instead of naming the use case “Deposit Function” or “Deposits,” for example, we would label it “Make Deposit” or “Deposit Funds.”

Expect the use case diagram to change

Expect your diagram to change over time. Eliciting requirements, regardless of the model used to record the requirements, is an iterative process. Not only will requirements change, but details of the elicited requirements emerge as we know more. Therefore, it is helpful to use stickies for actors, use cases, and interfaces during elicitation until your diagram stabilizes. It is far less frustrating to move stickies than to redraw the entire diagram every time a change occurs. Similarly, do not spend energy trying to align actors with use cases. That alignment will change as the diagram changes. If is far easier to group actors after the diagram stabilizes. Also, there are tricks for simplifying the diagram when the model becomes complex and with the use of dependent relationships, which we’ll discuss in a future article.

In the next article, we will discuss the importance of a use case narrative and how to create one.

Making the Most of a Bad Project Client Relationship

Written by Brad Egeland on November 2, 2015. Posted in Articles. 7 Comments on Making the Most of a Bad Project Client Relationship

I realize this is probably a fairly confusing title. But we do sometimes have those bad client-delivery organization relationships. Either they were bad on an old portion of the project, and you just took over a restart of the project, or possibly they lack confidence right out of the gate on your ability to deliver.

Maybe the project sponsor was stuck in their position against their will, and they’re determined to show you that nothing you can do will make them happy.

Is this a no-win situation? It sounds like it, but it doesn’t have to be. I’m not saying you can certainly succeed. You may be doomed to fail no matter what you do to turn things around, but there are a few steps you can take to show your client that you are determined to win them over. Now, bite your lip, suck it up, and try out one or more (or all) of these actions in an attempt to turn that customer frown into a smile.

Meet face-to-face. The very first action – and probably most obvious and possibly most painful depending on why the client relationship is sour – is a good old-fashioned face-to-face meeting. Or at least a good face-to-face conference call. This meeting is project manager to project sponsor. Ask how things are going, what is going well, what is causing concerns, and how confident they feel in your team’s ability to deliver. In fact, have them go over their top five concerns about the project right now. Then proceed to address each of those concerns. First do this in the meeting with a conclusive answer or a “we’ll take that under advisement”. Then tell them you’ll report to them within a week on how you intend to address those concerns.

Change your project status reporting structure. Change how, what, and when you’re reporting project status on the engagement. This may not sound like anything earth shattering, but trust me it can be vital. There are those clients who get frustrated because they don’t feel like they are regularly receiving the information that will make them confident and comfortable with what is happening on the project. Ask them if they feel like the current status reporting structure is meeting their needs. If not, change it so that it does. Listen carefully, and then act.

Related Article: Are Your Sponsors and Clients Satisfied?

Get your senior management involved. This is one of those situations where you have to take this action before your customer does. Getting someone from your executive team to sit in on one or more project status calls can send a great message to your client. It says, “you are important to us…very important.” Plus, if you do this proactively, the client will enjoy the attention rather than see it as an opportunity to complain or request changes. Being proactive and changing things around a bit on a stale or stalled project usually has a very positive effect on customer confidence and satisfaction. Your attempts to gain executive visibility for the project and the client will not go unnoticed by the project customer.

Perform a scope review on the project. Much like everything else on this list, doing a scope check mid-project is another action to help the project customer gain confidence that what they will be receiving is, indeed, what they want and are paying for. A good time to run back through requirements would be just before testing preparation as it will provide your client with a nice segue into building test cases and test scenarios for user acceptance testing (UAT). But this will also give them complete confidence – or as complete as possible – that you have built the final product with all requirements in mind. This review can also be accomplished – to a degree – by creating a requirements traceability matrix. A good sit-down with the client to review scope is a nice hand-holding gesture and gives them greater confidence in the delivery team’s ability to actually deliver.

Conduct an on the spot lessons learned mid-project. Finally, (or possibly next) halt everything and conduct a lessons learned session on the project with the customer. Discuss the good, the bad, and the ugly on the project so you can improve or take corrective action (if that is even necessary) rather than just learn for the next project. You will gain lots of points with the client just by being bold enough to do this mid-project and attempting corrective action if needed. Nothing says you value the client relationship like doing something of this magnitude.

How to move forward

A bad relationship just may remain a bad relationship no matter what you do. But I guarantee you that it definitely will if you choose not to do anything. Do something about it. Change something, talk to the project client, open up new lines of communication. Just don’t ever bury your head in the sand. That is the absolute worst thing you can do. Within a week, they will be contacting your CEO.

Be proactive, take corrective steps – and those corrective steps should start with one, two or possibly all of the five actions I’ve outlined in this article. Try out these five actions – something will improve. And as you try out each – ask yourself and your team if things seem to have improved. And then, be bold, ask your project client for feedback. Ask if they have seen positive changes. The worst thing they can say is, “not really” or “not yet.” But at least they will have seen action, and that is all good.

What about our readers? When have you had a project relationship that was strained and what did you do to try to turn things around and win back or gain customer confidence? Did it work?

How to Stop the Long-Winded: With Class

Written by Kupe Kupersmith on October 27, 2015. Posted in Articles. 18 Comments on How to Stop the Long-Winded: With Class

I was on a call the other day with people from around the world. Usually, these calls are awesome. The fact that I get to work with people from Australia, New Zealand, Canada, Italy, and beyond is amazing to me. Life is not always awesome, though.

This last call was not fun. Apparently I was one of those long-winded people. A reaction from the meeting chair ended up hurting my feelings. I felt shut down. I stopped sharing my ideas. Some of you may be saying, “good, you and the other long-winded people need to keep quiet for a while.” Maybe you have a point. The short term goal of shutting me up moved our agenda along. The long-term impact was I stopped providing ideas in the meeting. That is not a good thing.

What happened was we were discussing a topic and asked to provide questions if we had one. I had a question, so I started in. My question was not yet well formed. I started talking trying to formulate the question. I am an extrovert, so I talk to think. At some point during my dissertation, the chair of the meeting piped in “Kupe, Kupe, Kupe!” I don’t know maybe there were 10 Kupes before he got my attention. I was trying to talk fast so I could get to my question. I was not rambling for the sake of rambling, I promise! I finally stopped and he said, “Kupe, you are going on and on, do you have a question? WHAT is your question?” That’s when my feeling got hurt, that’s when I stopped talking out loud and said “whatever” in my internal voice. I think I even threw up the “Whatever” sign. You know, making a “W” with your 2 hands. We didn’t have video, he couldn’t see me. I’m 44, but I can still act like a child! I ended up asking a question. But you could hear a new tone in my voice. I became disengaged. For the rest of the meeting, I shut down.

I know some of you are saying to yourselves, “jeez Kupe, man up. We need to have thicker skin than that.” Believe me, I know. I do have pretty thick skin. My kids say that they love that I don’t care what others think. The context there is I do goofy things trying to embarrass them. Needless to say, I am very comfortable with who I am, my thoughts and beliefs and don’t get my feelings hurt often.

The point is, even people with the thickest skin can get their feelings hurt or get defensive. You need to make sure you are facilitating meetings where people feel they have input. Where they feel comfortable sharing their thoughts. The goal is buy-in. I talk about this more in a post titled “Your goal is not to shut people down just for the sake of sticking to an agenda.”

There is a real problem here. You need to make people feel comfortable sharing their thoughts. You also only have so much time. The long-winded are a challenge. The ones that don’t speak are a challenge too, but they don’t take up any time. What are you to do?

In a face-to-face situation, peer pressure comes into play. When you have a long-winded person going on and on, people start shifting in their chairs, looking at their phones, etc. People start to see their team’s reactions and may adjust. In a remote session that peer pressure is gone. Many people are on mute and you don’t see anyone. It actually makes the long-winded even longer-winded because they are not getting feedback. In my case, I was not sure people on the call were understanding where I was going with my thoughts, so I kept going. That is until the rude “KUPE” to the tenth power came from the chair.

Some would say, it’s all about relationships. If you have a good relationship with the people you work with, then you can be less politically correct. I am a huge believer in relationships and promote it all the time. Even if you have great relationships with others, you need to be careful. I have a great relationship with the chair of this meeting. I have a really good relationship with the others on the call. In my situation, the chair did need to stop me. In hindsight, I was really long-winded. In many of your meetings there may be a person or two that needs to be stopped.

Is there a better way than coming across as abrasive? Is there a way to do this without hurting others feelings? More importantly, is there a way that does not stop engagement from others?

My tip is don’t leave it up to the person running the meeting. That puts all of the pressure on one person to keep a meeting running smoothly. Eventually, that person snaps and comes out with a statement that can shut down the talker. It needs to be clear in the meeting that everyone has the right/ability to get the long-winded to wrap up. Come up with a code word or sound. When that sound is made or word spoken the talker needs to wrap it up. This can be used for face-to-face meetings too, although it is critical for remote meetings. Make sure everyone knows it is not personal. It’s about making meetings more efficient.

Don Palmer from The Dallas Federal Reserve Bank recently told me about an analogy he used to show his executives the effect of showing displeasure when project managers present project status reports that included issues. He refers to it as hitting the goalie. Don explained there is a rule in hockey that prohibits players from hitting the opposing team’s goalie. This originates from not having many people want to play goalie. Kids want to play offensive, goal-scoring positions. So, there were not a lot of goalies out there from which to choose. If a team hit the goalie and the goalie was injured, teams would have to go to a backup goalie. Then if the backup goalie was injured, there was no one else left to play the position. This would completely alter games. In the project status world, Don explained if you badgered the project manager for bringing up issues during status reporting, PMs would begin to present all positive results during the project. Then in the end the projects would fail because they were hiding the truth all along to avoid the public badgering. This behavior did not allow executives to make decisions along the way to get the projects back on track. Don explained that badgering a PM is like hitting the goalie and pushed to have a “no hitting the goalie” rule. Now in status meetings if one executive is badgering a PM, another executive will say, “you are hitting the goalie.” I think this is brilliant. This is now a term that everyone understands and respects. It also results in PMs sharing the information as it is and not sugar coating the status of their projects.

There is no silver bullet. Feelings will get hurt. Your goal as a leader is to work consistently towards obtaining full participation. The outcome you are looking for is buy-in from the group. You gain buy-in by allowing the team to share their thoughts.

To not hitting the goalie,

Kupe

Career Corner: Attributes Of An Exceptional Project Manager

Written by Helen Sabell on October 5, 2015. Posted in Articles. 15 Comments on Career Corner: Attributes Of An Exceptional Project Manager

The most successful project managers are those who can persistently deliver on time and within budget, with projects that match or exceed stakeholders’ expectations and who can effectively oversee a project from beginning to end. They are highly skilled leaders who can bring together all the stakeholders in the project and lead the team to completion of their goals. They understand that leadership and people skills are even more important to good project management than any other attribute.

The more experienced project managers also know that if you don’t understand the stakeholders side of project management, it doesn’t matter how good your methodology or your resources are. If you aren’t managing stakeholders correctly, you may deliver on budget but may not meet the client’s needs, leaving them dissatisfied.

Here are some things a project manager can do in order to be exceptional.

Set A Clear Vision

A great project manager can anticipate and intercept problems that could jeopardise deadlines, budgets, and the overall acceptance of the project. In spite of all difficulties they may face, project managers need to have a clear vision of the direction in which they are heading. They should commit to this vision and try to explore the ways of achieving it. Their frame of mind should consider any potential obstacles that could deter them from achieving their goals.

Related Article: Top Ten Must-Have Skills for a Project Manager

Be Organized

Organization is a key characteristic of a great project manager along with excellent time management skills. Organization can be displayed in various ways, for instance, the ability to stay focused on the big picture and to prioritize competing responsibilities. There are numerous aspects and tasks in most projects that have to be completed, and it is crucial to stay on top and in control of everything at all times. Prioritizing work for their team is a critical aspect of what a project manager has to do!

Be Honest and Reliable

Honesty and reliability are essential traits for a project manager. It is critical that the manager means what they say. If the project manager consistently fulfils their promises and holds those accountable in a fair way, the team members will then respect the manager’s integrity and loyalty.

Become A Natural Leader

Project managers have to influence and interact with a variety of stakeholders. Employers want project managers who can improve their team’s performance to help optimize accomplishments. They need to focus on their team’s performance to reach milestones by encouraging participation, keeping open a strong line of communication, and holding team members accountable. As many project team members do not report directly to the project manager, they have to find ways to motivate those workers where they do not have direct influence. These employees can essentially make or break a project. Project managers need to be able to inspire the confidence of stakeholders in the event the budget or timeline needs to be negotiated, or additional resources are needed. Project managers should command authority naturally and be optimistic leaders who are viewed in a favourable way. These project managers are highly valued by their company.

Be a Good Communicator

The project manager needs to acquire the capacity to communicate a clear vision in order to increase their leadership.

It is important for project managers to have a clear vision of the project before they begin to communicate. Otherwise they will not be able to explain themselves in a simple and understandable way. Begin by integrating all the objectives of the project – financial, professional, technical, process, strategic and tactical. It is extremely important to listen to your client and develop a plan to exceed their expectations. Successful project managers use emails, meetings, and reports to effectively communicate their ideas, get decisions made, and resolve problems. You will need to discuss your client’s project in the manner most relevant to the audience.

Understand Business Strategy

Project managers must be able to see how their projects fit into their company’s strategy. This will serve them extremely well If they can expand their project management expectations into a business context. They need to look beyond the skills necessary for project management. The more context they can show, the more value they have to the company.

be Pragmatic

Good project managers focus on getting work done with the resources that are available to them.

Companies seek project managers who can meet deadlines and stick to budgets, even when things do not go to plan. It is essential for a project manager to really portray their flexibility. This is the perfect opportunity to share what obstacles they have encountered, how they have overcome them and what resources or management tools they used. There are constant changes so they must be extremely flexible. Sometimes it is common for project managers to be a little too analytical. They often over analyse before moving ahead which can slow the progress of a project.

have Enthusiasm

It is important for project managers to create an encouraging atmosphere and demonstrate on a daily basis their confidence in the team, in all its members and in their capacity for everyone involved to create a successful project.

It is a common first instinct to not trust, as the slightest error could prove fatal. However, a lack of trust will be felt by your team. You need to entrust your team and although a task may be difficult and critical, provide them with all the necessary support to succeed. We all have different styles, but it is important to trust others.

be Empathetic

It is no surprise that project managers rely on others to be successful. Project managers cannot effectively influence others if they do not understand what motivates their stakeholders. They need to learn and understand stakeholders’ concerns and worries about a project, take those concerns seriously and address them.

Companies will continue to look for project managers who can deliver results on time and on budget. It is important to show hiring managers you can outperform other project managers to improve your chances of making a lasting impression.