Project Management: Having Vision

I was sitting in church this weekend listening to the sermon and our pastor about the visions and goals of our church – one of those things he does every year about this time as summer and vacations end and it’s back to work and school for everyone. He mentioned Proverbs 29:18, “Where there is no vision, the people perish; but he that keeps the law, happy is he.”

Immediately, I thought…wow…that applies so well to everything we do. And yes, corny as I am, it even applies to project management and the way we manage our teams, customers and the engagement as a whole.

The Project Vision

Vision. We must have vision. As I discussed in “Begin with the End in Mind,” we must understand where it is we’re going and how we’re trying to get there so that we may guide the project and the skilled resources that we’ve been charged with so that we can enjoy a successful engagement.

It’s easy in life and when managing a project to get bogged down with the day-to-day activities that we’re trying to stay on top of. Fires confront us on our projects more days than not and tend to throw us our daily, weekly and monthly targets. Those fires can potentially throw us off the course we set for the project in the first place.

Risks become realized, resources get moved from our projects, and our customers change courses on us with a big change order, scope change or major shift of priorities. Stress sets in and, if we’re not grounded in our direction for the project, we can easily get bumped off course.

I’m not saying anything earth-shaking here, I know. We don’t always take enough time to look ahead at where the project is going and keep our thoughts and understanding on what’s important for the engagement, our customer and our organization. And if we fail to do that, think how far off course our team can get - the team that looks to us for guidance, approval and on-going assignment (and motivation).

Summary

It takes a special kind of leader to remain grounded in what’s important and stay the course. You’ve heard the term “fake it till you make it”, I’m sure. That applies here. As project managers, we’re ordained leaders. We may not be great leaders yet…may not even be very good at it at times, but we’re all learning along the way.

We often have to improvise and “fake it till we make it.” The key to this, in my opinion, is one of those characteristics of a PM that I mentioned…stubbornness. If you tend not to let yourself and your decision-making be swayed by the daily occurrences that go on around you…the bumps in the road…then you’ve already won half the battle. Because when you’re stubborn like that, you have a better chance to stay the course on the project and remained focused on the end goal.

We have to adjust mid-course – it nearly always happens – but adjust with that end goal still clearly in mind and then the success of the project overall is still not put in jeopardy. Remember, the customer doesn’t always know what they want and we can’t act on their every whim…we’re the experts and we must guide both our team and our project to the end goal.

Job : Federal Systems Project Manager (Washington D.C)

Location: Washington, DC
Categories: Wireless
Full Title: Federal Systems Project Manager
Compensation: 85 – 100K

Company Description:

The client is a leading manufacturer of scalable, integrated security management systems. Their products can be found in a wide spectrum of markets: government, commercial, education, transportation, healthcare, retail and banking. They have been at the leading edge of access control technology for over 30 years, and their next generation of products will bring the core aspects of security to the next step beyond integrated solutions.

Responsibilities:

The Project Manager will be responsible for ensuring customer expectations are met. This requires daily tracking and driving requirements such as:

• Overall management of the project direction as related to functionality and schedule
• Insuring adherence to project management and software development life cycle and best practices
• Managing the company’s performance on project tasks
• Providing overall project planning, monitoring and control and periodic status reports for Senior Leadership
• Reviewing and approving architecture and product direction
• Securing acceptance and approval of deliverable from the project sponsor(s)
• Be responsible for status reporting, risk management, and escalation of issues that cannot be resolved within the team
• Respond to customer requests for information in a timely manner. Such requests include: system design support, product feature and capability descriptions, price quotations, and review/response to system requirement specifications.

Significant experience working with the federal government is mandatory. The candidate chosen will either have a federal clearance or be able to obtain one.

The Project Manager will have a deep working knowledge of security components and systems provided by Security Manufacturers, such as Access Control software, panels, readers, IDS, DVRs, printers, Intercom systems, IP video, storage and IDS. The Project Manager will understand the Federal standards for security meeting FIPS-201 standards including readers, and card technology.

• Must be professional with strong written and verbal communication skills.
• Must have strong IT knowledge with a deep understanding of computers, operating systems and networks.
• A college degree (or equivalent) is preferred with at least 10 years of experience in a technical role in the security industry.
• Project Management Professional Certification (PMP) is highly desirable.

Compensation:

The position of Project Manager will be compensated with a base salary commensurate with experience and meeting the above requirements, a quarterly bonus based on sales team performance, and a benefits package that includes options for medical and dental insurance and 401(k) with company matching.

Apply here..

Managing Multiple Projects – Stagger the Lifecycles

I was reading a book on managing projects and how to handle multiple projects at once and this concept jumped out at me. Not that we don’t all know it…I think we may just take it for granted.

Re-Stating the Obvious

I’ve mentioned many times that I’ve usually been managing multiple engagements at once – and I believe that most project managers are probably in that situation much of the time. Usually, you have a group of 5-6 active projects that you’re overseeing at any given time. What I have never discussed is the concept of how you survive that – at least not in any detail. Not that I’m going to really break any new ground here…but it was a bit of a revelation (for some reason) to me that having these projects in much different points in their project life cycles is what keeps us sane. I guess I was just taking it for granted.

One of the most frustrating times I’ve had recently was about 2 years ago when I actually had to kickoff two projects within a week of each other (one was the project where my business analyst ended up crying in the hall and during a customer meeting – see “The Worst Project I Ever Managed”).

Avoid Overload

Having your project life cycles staggered is definitely one key to sanity and greatly increases your chances of success. One can not sanely go through life managing 5 projects that are at the same point in their project life cycles at the same time. The demands on the project manager vary by phase – and are weighted more heavily at the front end and usually then again around Testing and Deployment. The lull usually occurs with Design and Development – phases that require much more attention from business analysts and developers than the project manager other than general oversight and reporting.

As happened with me during that one approximate 6 week period nearly two years ago is that I kicked off two projects a week apart and then took both of them into Exploration (that’s where the breakdown occurred). Kickoff and Exploration are both PM-intensive phases and I was stretched thin along with having 4 other less time-intensive projects to manage also. I’ve written about how the situation was righted, but it still took awhile for sanity to return because even though the situation with the customer on the initially troubled project was corrected and expectations were reset, we were all still stretched too thin.

Summary

If you find yourself assigned to projects that are critical, visible, vital, etc. etc. AND they happen to have PM heavy phases overlapping, then do yourself, your customer, your team and your organization a favor and step back to assess the situation. Don’t try to be Superman. If you can’t provide each project the amount of attention that is needed, let your management know. Better to offload a project than to fail at one or more of them. Way better…. There’s nothing wrong with admitting when your plate is too full.

Risk Management: Analyzing Threats to Your Project

Another section from Gary Heerkens’ brief case book entitled “Project Management,” was utilized for much of the material for this article. This section deals with how the project manager and team goes about analyzing risks and managing “high-threat” potential problems during the engagement.

Having analyzed the possible risks to the best of your ability, at this point, you and your project team have identified a substantial list of potential problems. You’ve tried to quantify the extent of these problems and their potential effects on your project. The big picture, though, is that you simply don’t have the resources to deal with every one of these potential problems.

So how do you narrow the list to a manageable size? How do you identify the problems that threaten you the most and therefore demand your attention? There are a number of methods for shortening the list. Should you even shorten the list? That depends on the project and how you want to manage the risks and how you’ve agreed to manage the risks with the customer. If your list is quite extensive, then, yes….it should likely be shortened…but how?

Analyzing the Biggest Threats to Your Project

One of the most common and straightforward methods consists of making subjective judgments about two characteristics of potential problems—probability and impact. These terms mean exactly what you would expect. Probability is the likelihood that the potential problem will occur. Impact is the seriousness or severity of the potential problem in terms of the effect on your project.

Once the probability and seriousness have been identified, determining the high-threat problems becomes a simple issue of ranking based on the two factors.

Taking on the potential high-threat problems will obviously consume resources so it is still critical to determine a threshold at which you will take on the risk or threat and below that threshold you’ll just have to leave it on the list and monitor it as the engagement progresses without taking active mitigation action unless it becomes necessary.

Responding to High-Threat Problems

There are a number of ways to address the high-threat problems you identify. Let’s examine all of the options for dealing with risk and potential problems:

Avoidance. In avoidance, you choose a course of action that eliminates your exposure to the threat. This often means that you’re now pursuing a completely different course from what you’d originally planned. The space shuttle program provides an excellent study in avoidance. Many flights are carefully planned and then, because of marginal weather conditions, scrubbed. Delaying the takeoff of a space shuttle mission because of a weather threat is a perfect example of risk avoidance.

Transfer. The most widely quoted example of risk transfer is something we’re all very familiar with—insurance. Risk transfer does not “treat” the risk; it simply makes another party responsible for the consequences of the risk.

Assumption. This means that you are aware of the risk, but choose to take no action on it. You’re agreeing to accept its consequences or to simply deal with them if it happens. That’s essentially how you’re treating threats that fall below the threat rating described above. Assumption is also a valid strategy in situations where the consequences of the risk are less costly and/or less traumatic than the effort required to prevent it.

Prevention. Prevention refers to action taken to reduce the probability of occurrence of a potential problem. Ordinarily, it will be your first course of action in dealing with high-threat problems. Prevention begins with identifying the root causes of potential problems. Determining root cause may allow you to identify preventive measures that could reduce the probability that a given problem will occur. Be sure to revise the project plan to incorporate any preventive actions that you intend to take, so that they’re not overlooked or forgotten.

Mitigation of Impact. This strategy aims at reducing the negative effects of a problem. You’re taking measures to lessen the impact. For example, installing air bags in automobiles does nothing to reduce the probability of accidents, but it may significantly reduce the effects. It’s important to note that mitigation tactics may be viewed as a waste of time, money, and effort, if the potential problem does not occur.

Contingency Planning. Contingency plans are specific actions that are to be taken when a potential problem occurs. Although they’re intended to deal with problems only after they’ve occurred, contingency plans should be developed in advance. This helps ensure a coordinated, effective, and timely response. Also, some plans may require backup resources that need to be arranged for in advance. Contingency planning should be done only for the high-threat problems that remain after you’ve taken preventive measures.

Project Planning: Evaluating the Political Environment

We’ve talked a lot about the act of planning your project. Review the statement of work (SOW)…check. Review the estimate from Sales…check. Request your project resources…check. Review the draft project plan and revise it – vigorously…check. Plan for your kickoff session with the customer…check.

What hasn’t really been discussed is the act of evaluating the political environment within your organization and the customer’s organization. It may be something you can’t always do too much of up front, but it is something that will have to be revisited and performed throughout the engagement. Here are the basics of what needs to be done up front and revisited in order to more successfully plan your project.

Consider the potential effects for your stakeholders. Once you’ve identified all of your project’s stakeholders, you should take that process one step further and identify who stands to gain (or lose) if your project succeeds and who will gain (or lose) if your project is deemed unsuccessful. It can be of value to understand and appreciate the nature of everyone’s stake in your project. Use this information to your advantage – it can be critical information to have on hand if you need roadblocks removed or key resources and skill sets made available to your project. Stakeholders can help make things happen.

Identify whose support will be needed. Try to identify who’s in the best position to help and support your project. More of the same from above. Keep this list close by throughout the project – because you will hit roadblocks and some of them may not be able to be overcome by your will and effort alone.

Identify who is likely to work against you. Identify the parties who may feel threatened by your project or who, for whatever reason, would not like your project to succeed. What you do with this list depends on the situation. At times, these individuals need to be avoided…and at other times they may need to be included and massaged to help ensure positive results. Power can definitely shift during projects – be aware.

Secure a project sponsor. Identify someone in management who can serve as a sponsor for your project. Sponsors are typically members of management who have a significant amount at stake in the success or failure of your project. Sponsors can work through political issues that are beyond your sphere of influence.

Address unrealistic targets or constraints. If your proposed project targets, specifically schedule and cost, exceed management expectations, you may be forced into a situation where you’re pressured into accepting cost, schedule, or other targets that are unrealistic. If this happens, I’d urge you to pursue either or both of these options:

1. Respond with a data-driven analysis that suggests that the project targets are unrealistic.
2. Continue to publish documents that display your original cost and schedule targets. Once you publish documents with unrealistic targets, you’ve pretty much sealed your fate and doomed yourself to project failure.  Don’t give in…stand firm if you know the targets are unrealistic.

Summary

Careful planning doesn’t guarantee project success, but it certainly doesn’t hurt. Failing to plan is planning to fail. Look at all the angles – consider who can help and who can hurt and act accordingly. You don’t have to make everyone happy – that’s for sure. But there are many eyes on your project and many individuals who stand to benefit from your project success. Know them and use that info to your advantage.