06/29/2017 by Jackie Dembinsky Tags: Sale
We’d like to help you celebrate too! Take advantage of our holiday sale. Buy one, get one 50% off.
Don’t forget, FastTrack Schedule is available for Windows and Macintosh machines, so feel free to mix and match to suit your needs. Pick two Window’s, two Macintoshes, or even one of each.
Project Managers are organized in everything they do, right? Well, I can say that I’m not.
And when I was attempting to change a tire on our full-sized 12 passenger van… I learned that I’m even less organized than I thought. My little kids were helping… so at least that aspect was fun.
The worst part? Everything else. I hate redoing work more than just about anything else. And I’ve been an application developer and a project manager long enough to know that rework usually comes from poor or incomplete planning/communication. I try to avoid both, but in the case of my flat tire, I failed.
What should have taken me 30+ minutes with some advanced oversight and planning, took me about four hours and a lot of unnecessary pain, sweat, and aggravation.
If I’d had my project manager hat on, I would have gone about it all differently. I was stubborn … and I was not planning wisely or planning at all.
The end result? Far too much rework and extra effort … and when you are talking about jacking a big 12-passenger van with a raised roof up and down three times, that’s too much rework. And later I realized that my very nice retired neighbor who rebuilds cars in his custom garage on his lot probably has a big hydraulic jack. Then I really understood how poorly I planned this out.
The moral to my story is this… if we don’t pre-plan well enough, we can end up wasting:
And all of that equals wasted money.
Thankfully, in my flat tire project, I didn’t end up having to spend more physical money. But if you account for how much my own time is worth, then I lost money. But if that had been a project I had sourced out with four $150/hour resources working on it – even the extra, say, three hours would have resulted in $150/hour x 3 hours x 4 project team members = $1,800 of extra time/dollars and that’s just one task. If you end up being a poor planner throughout a project you can see where a couple thousand dollars can easily become $100,000 and a failed project … fast.
Summary / Call for Input
Plan, plan, plan and plan some more.
I knew going into my project that I needed to plan. I let other things get in the way of that … for me this time it was the fun of getting my little ones involved and starting before planning.
Sometimes this happens when we let senior management push us into starting a project before we’ve properly planned for it so they can show progress and results. Sometimes it’s a project client pushing us to skip some planning and get started in the name of saving money.
It doesn’t work that way 9 times out 10 though, does it? Unless everything happens flawlessly, poor planning will usually end up costing us in the long run.
Readers, can you relive an incident – personal or professional – where poor planning or a lack of planning cost you time and money … and frustration? Please share and discuss.
This may seem like a simple question, but the answer is bigger than we think it is. We’ve all grown somewhat immune to the mocking of those in charge – you see the President of the United States and other world leaders mocked on TV and other media all the time. But really, what about the leadership of your company? Do you have confidence in them? Do you think they have your back? Do you feel like they’re leading you, your co-workers … even your customers in the right direction?
I think the answer for many of us is often ‘no.’ And that’s sad. Why is that … why do we feel this way?
Let me look – generically – at situations I’ve both encountered personally at organizations I’ve worked with and for, as well as situations I’ve seen at customers and clients I’ve worked with. I’ll try to not be too specific so you can’t tie a situation back to one of my past employers – but you know who you are!
One Fortune 500 organization did very little support their PMO. I was around long enough to see it created, witness it flounder and fail, see it disassembled, and then see it re-assembled. And through all of this, there were other organizations within the company who were acting in renegade mode leading projects – and getting support from executive leadership to do so (crazy!) – while the actual PMO struggled and disintegrated. Rarely have I personally witnessed such an extreme waste of time, effort, good people and good money.
Another organization would continually go through basically what amounted to the ‘flavor of the month’ for continuous improvement programs to the point where employees just went through the motions and you could see it affect their jobs, their attitudes, and – the worst part – how they represented the company to customers and potential clients.
A gaming/hospitality company – a giant in the industry who merged with another industry giant – had some of the worst IT leadership I’ve ever seen. I personally was brought in to lead the application development portion of this organization and the first thing the IT Director did was walk me around and point out everyone he wanted to fire – as we were walking by their desk. Talk about a real people person – a real morale booster. I will happily say that I didn’t end up spending too long at that organization and I fired none of them. They didn’t need to go – it was the IT Director who needed to go and he did…eventually.
How does this relate to project management? It does in each and every way because project management – especially in an IT organization – is ingrained (or at least should be ingrained) in nearly every aspect of the organization. After all, the projects can come from anywhere, right? PM really knows no boundaries – nearly anything can be a project.
The key is that your project management structure … whatever that may be, must be supported by your executive leadership if it’s going to remain viable within the organization. If your CEO on down does not support it, then rogue groups may end up leading key projects – circumventing the PM process. I’m not saying that’s ALWAYS a death knell for a companies PM group and processes, but customers will eventually become aware of the internal turmoil and inconsistencies that come with all of that and you can start to see a reduction in customer confidence and satisfaction as a result.
Get the support of your CEO and other executive leadership. Invite them to your some of your weekly PMO group status meetings. Have them sit in on some customer project status calls. Not only will they become involved and see the PMO and project management benefits in general, but your customers will feel extremely important when your CEO takes some time to be part of their project.
What about our readers? Have you suffered through these types of leadership issues, project management / PMO issues? Please share your experiences and discuss.
Sometimes what you’re really trying to solve is a bit hidden. The customer may not see it and you might not at first glance either. But it is your responsibility to make sure you always go that extra mile to make sure you are addressing the real issue and not just a symptom that the project sponsor sees and what seems obvious to everyone.
It’s not always easy to truly identify what is the real project. On the surface, it seems obvious. The customer comes to you with ‘x’ need and you work with the customer on business processes and requirements and move forward with work on a solution for that customer. You have a project involves working to solve the customer’s identified need.
However, it’s not always that easy … and as the Project Manager, you must assume that the customer doesn’t always know what it is they want or even what their true need is. Identify that true need, and you’ll be building a solution that keeps the customer happy.
Problems and opportunities can arise almost anywhere inside or outside the organization. Problems are typically driven from within and frequently relate to improving organizational performance. For example:
|A department that’s overwhelmed with paperwork.||Simplify procedures.|
|An organization that constantly faces the prospect of worker strikes.||Improve management/employee relations.|
|An insurance company that has branch locations spread across a wide geographic region.||Communicate effectively among branches.|
Problems are generally regarded as negative. Opportunities may be viewed as their positive alter ego.
Opportunities are often driven by external forces. More common examples can be found in the areas of product development or product enhancement. These opportunities are often the response to a perceived need in the marketplace. In other words, sometimes a problem leads to opportunities.
The term “true need” refers to the most basic problem to be solved. Identifying your project’s true need can, at times, be tricky. But it’s absolutely vital that you as the Project Manager understand what the true need is.
Why? Because many will judge you as a project manager by your ability to solve the original problem. Solving the original problem equates to satisfying the true need and you and your project team often have to dig to find out what that true need actually is. You cannot be certain that you’ll satisfy the true need unless you know what it is. The problem is that when you’re assigned to manage a project you may not be presented with the true need explicitly. Terminology can become confused: what’s described as a need may actually be the solution to a need.
One of the most reliable methods for uncovering the true need is to ask the right people one simple question: “Why?” However, as you seek to uncover the true need, you can expect to encounter some resistance.
If you ask questions rather than digging in and getting the project going, some within your organization may assume that you’re not moving forward. However, asking the right questions of the right people can often lead to some startling discoveries.
Readers – have you had many projects where the real need was buried and the customer was actually coming to you with a symptom? I have … and the end result would have been disastrous if my team and I had only delivered on the symptom rather than digging for the real problem. Please share your experiences.
In Part 1 of this two-part series on figuring out whether or not what we have viable project … we looked at what brings us to the go / no-go decision point and how we review a project from both a justification standpoint and a feasibility standpoint.
Now, in Part 2, we’ll consider how to:
Once you fully understand the project’s goal and establish that it is justifiable and feasible, you’re ready to determine the best way to satisfy that need. (You may wish to review Part 1 of this series.)
Although I’m using the term “you,” proper execution of this step really requires the input of many individuals. If you’re fortunate enough to be involved at this stage of the project’s evolution, you should be actively working toward building a team that can work with you from this point on.
The process of identifying the optimal way to satisfy the project requirements begins with generating a list of potential solutions. This process is made easier when these elements are included:
Obviously, you can’t pursue every idea identified through processes like brainstorming.
After soliciting all reasonable alternative solutions, the project team needs to pare the list down to only those that are worthy of further development, investigation, and definition.
You can reduce the list by comparing each alternative against predetermined criteria. This is where the Requirements Document begins to add significant value. The process for selecting the optimum solution begins by evaluating each alternative solution in terms of how well it satisfies the most critical aspects of the project requirements, such as budget constraints or strategic alignment.
You may also wish to use other requirements-based considerations, such as the likelihood of technical success or the anticipated impact on existing products. This initial screening will allow you to shorten the list of potential alternative solutions to a manageable number (I would recommend two to five).
At this point, the selection process becomes much more rigorous. Each potential alternative should be evaluated using two basic types of criteria: financial and non-financial.
Readers – how do you feel about this process? How does it match up with your organization? Do you have similar processes you can share and discuss?
Not every project is cut and dried and definitely a project – some have to be fleshed out and decided upon … is this really something we should be doing and is this the best way? If not … what is? Please share your thoughts.
In one of my past lives in corporate America, I worked at a very large, Fortune 500 engineering and aviation firm that featured a central Project Management Office (PMO). There existed a requirement for all project managers to go through the following exercise on the larger projects (not all of the smaller projects required a formal process like this):
Two things to understand first before going any further:
The sole purpose of the Tech Council and the PM presentations was to ensure that the project was worthwhile taking on (since everything was internal and really represented a shifting of money from one department to another rather than actual income – except where costs were being saved) and to ensure that legacy technology was not going to be used in a long-term solution when that technology was planning to be phased out and unsupported in the near future.
So, in a sense, the Tech Council was basically a go – no-go decision point early in the project. Even though it was early in the project it was a good time to ask:
Buried in these four questions is addressing the issues of justification and feasibility. You should deal with both issues before continuing no matter what customer base you’re servicing – internal or external. If not, you run the risk of wasting time and money on problems that should not or cannot be solved.
Particularly financial justification—is very difficult to assess at the requirements stage, because not much is really known about the project. Nonetheless, it’s wise to try to assess whether or not you can justify continuing the project. You may be able to do this by executing a simple cost vs. benefit analysis.
The benefit component is relatively easy to estimate: it’s the value of satisfying the need. In many cases, this is nothing more than calculating how much the problem is costing today. Estimating the cost of the solution is more difficult, because you’re not sure what you’re going to do or how you’re going to do it. One approach you may wish to consider consists of working backwards through the financial calculations. By doing this, you can determine the most you’d be able to spend on a solution. If none of your proposed solutions can be executed for less than that amount of money, the project will ultimately be unjustifiable—at least from a purely financial standpoint.
This comes down to a basic question: Do you believe that a solution exists? In other words, can this problem even be solved? This step is referred to as verifying feasibility. There can be much subjectivity in this step; you should rely heavily on the judgment of subject matter experts (SMEs). In reality, the most that you can realistically hope to determine at this point is that the possibility of a solution is thought to exist. That’s OK. As with justification, all you’re trying to do at this point is preclude the expenditure of additional resources and money on problems that have no reasonable solution.
This step is referred to as verifying feasibility. There can be much subjectivity in this step; you should rely heavily on the judgment of subject matter experts (SMEs). In reality, the most that you can realistically hope to determine at this point is that the possibility of a solution is thought to exist. That’s OK. As with justification, all you’re trying to do at this point is preclude the expenditure of additional resources and money on problems that have no reasonable solution.
In reality, the most that you can realistically hope to determine at this point is that the possibility of a solution is thought to exist. That’s OK. As with justification, all you’re trying to do at this point is preclude the expenditure of additional resources and money on problems that have no reasonable solution.
In Part 2 of this two-part series, we will look at working to identify the best solution possible for the project need and whether it is feasible to proceed with the effort.
Readers – please be thinking about your own processes that you and your team or management go through to make project go / no-go decisions and be prepared to comment and discuss.
Bar Styles Resource View Announcements FastTrack Schedule Environment Budgets, Costs, Progress FastTrack Schedule Reports Layouts Filters and Sorts Misc Summary Graphs Tips and Tricks FastTrack Schedule Go All Posts Printing Resource Assignments Importing, Exporting, Exchanging and Sharing Training Tutorials & Help Work Calendars Consolidating Projects, Project Portfolio Management Schedule View PM Topics Templates