Overcoming Common Project Issues – Part 2
Posted by Brad Egeland
No matter how well you plan and no matter how organized you are, there are still some common problems that can rear their ugly heads and try to derail your projects. Sometimes, no amount of lessons learned sessions will get you past these issues, so we need to examine them further and discuss ways to eliminate them or at least minimize their affects.
In Part 1 of this two-part series, we discussed the first five of ten problems commonly experienced on projects. In Part 2 we’ll dive further into these issues as we examine problems six through ten.
#6 – Communication with top management while the project is underway is not effective
How do you handle the problem of poor communication with top management? Even when you make the effort to keep the lines of communication open, management may simply fail to keep you up-to-date on priorities.
Your solution: You cannot force top management to improve their communication skills, but you can do your best to present status reports, ask for continuing definition, and convey information to the top—even if your only avenue is the interoffice memo. If you can’t even get an executive to take time for a brief meeting, chances are your communication link will suffer. You may find that management does not respond to your requests or suggestions, fails to confirm project goals, and offers little support; but when the project is completed, you are told that “this is not what we wanted.”
In most cases, management wants to support you, and will try to maintain morale. So even though the problems seem formidable, if you make an effort to communicate, they can usually be resolved – even if you have to train top management in the development of communication skills!
#7 – The schedule is difficult to control
Coordinating the many ongoing efforts of your team members and successfully completing many different phases within the same limited time period may be a struggle. If so, examine the method you are using to develop and control your schedule. You may have to invest more time in developing a detailed network diagram and showing team members how to use it as a control document. Most instances of scheduling control problems are created by a lack of preparation in creating the schedule itself.
Your solution: Revise your methods.
#8 – Deadlines are not being met, and projects are completed late
You may have an excellent process for schedule control, and team members are working well together. But in spite of that, you simply don’t meet phase deadlines, and projects aren’t completed on time.
Your solution: Allow more time, or increase the size of your team. Your schedule is not realistic, and phases cannot be executed at the pace built into it. You may have been forced to accelerate your schedule because management imposed an early deadline. When you first organize your schedule, the realistic completion time will be dictated by the scope of the job. If the final deadline is unrealistic, convey this fact to management, explain why there is a problem, and ask for a later deadline or a larger project team.
Getting to the Actual Project
Posted by Brad Egeland
The real need? Does the customer know it? Do you know it from the initial information given to you? Let’s look at the following project scenario….
Dave walked briskly over to Bill’s cubicle. “Bill, I just got a call from Amy. She’s got a problem and needs our help. I’d like you to go over there right away and get the details. Figure out what she needs and take care of her.”
Bill was pleased to be assigned to one of his organization’s most valued clients. By the next afternoon, he was sitting in Amy’s office, carefully reviewing the documents she’d prepared.
“Bill, we need the capability of screening all of our incoming components before they come into the assembly line,” said Amy. “You’re free to do this any way you’d like; just make sure that they fall within these guidelines.” She handed Bill some design documents and a list entitled Incoming Material Screening Requirements.
Bill was happy that Amy had given him free rein in determining the solution to her problem. He studied the project requirements and formed a project team. Then, he and his team developed and installed the hardware and software necessary to check all incoming components for compliance with the screening requirements. It was truly a thing of beauty. Bill was proud of the job he and his team had done.
Less than a week later, Dave called Bill into his office. “Bill, Amy just called me,” he said. “They’re still having the same problem as before— too many rejects coming off the end of their assembly line. What happened?”
Suddenly Bill realized what had happened. He had just discovered Amy’s true need—the hard way.
(The above project scenario comes from Gary Heerkens’ book entitled, “Project Management.”)
I really like the example above. It’s simple, straightforward, gives you the impression that the problem has been solved through the project work and then BAM! … you realize that nothing has changed and you’re smacked upside the head with management questioning you wondering what you actually did on the project.
Four Principles to Guide Project Managers – Part 1
Posted by Brad Egeland
This Part 1 of a two-part article outlines the first two of four principles to guide you on your project management endeavors. It is not all encompassing, by any stretch of the imagination. And I would gladly welcome your feedback and input through comments on this article.
Be Conscious of What You are Doing
Luck should never be the plan for success as a project manager. Project success should not be accidental – at least not as an ongoing plan. It may work on short-term efforts or when you’re working alone. But it’s not a good plan for long-term undertakings or when you’re leading a project team.
A project, by definition, is something that has a unique aspect to it. Even if you are performing your tenth software implementation of something that is nearly identical to the previous nine, there are still going to be variables that make it different. The environment and IT infrastructure will mean performance variations that will need to be understood and handled, etc. Projects are difficult enough, leaving things to luck makes success that much more difficult to achieve. Plan well, create an effective plan, and utilize repeatable processes and reusable templates.
Invest Heavily in Front End Work
Do it right from the beginning. If you’re like me, you get a new piece of software or a new gadget of any type and the first thing you do is start to use it. Directions? Who needs ‘em?
When we kickoff projects, we need to have a different mindset. We need to get it right from the start. Invest in the upfront work. Don’t jump from handoff right into the project. Plan well up front.
Caution: Jumping in too quickly in project management is going to get you into big trouble in a hurry.
Negotiating for Specifications and Resources on the Project
Posted by Brad Egeland
In general, project manager will conduct two primary types of negotiations on the project. One will be with the project customer concerning project specifications and requirements and another with the various functional managers who control the personnel resources needed for the project.
Of course, there may be other types of negotiating throughout the project – usually concerning change order work and issues that may arise. I’ve written about these before and we’re aware of these types of negotiations, though they may or may not be necessary. The negotiations be discussed in this article are almost certain to take place.
Negotiating with the Customer
Negotiations with a customer occur at a project’s outset and are done to arrive at a project’s specification. It would seem to be a straightforward task: The customer explains what is wanted, and the project manager captures it in the specification and goes ahead with the project. This is not always the case, however. Some customers may come up with only a fuzzy idea of their desired product and may need help from the project manager to discover what is possible to be produced for them. This is where negotiating enters in the process: The project manager identifies the various tradeoffs to the customer and negotiates decisions regarding these tradeoffs.
The customer may not understand project feasibility, or what can and cannot be produced—and also may have come up with time and cost expectations that are inconsistent with what experience dictates. Resolving these types of problems also requires negotiating.
Basically, the key to negotiating is to clearly identify the needs of the person with whom you are negotiating. Then, you must tell this person exactly how you propose to meet those needs, discover the constraints limiting their efforts to help you meet those needs, and discover what they would accept as an incentive for their help.
Making Informed Project Management Decisions
Posted by Brad Egeland
Making decisions is part of daily life for any manager or executive. Some decisions may result in a change of strategy in personnel policy or employee training. Other decisions may result in undertaking a project to launch a new product line. A gamble often is associated with important decisions. Newspapers frequently report the names of executives who were rewarded for “making the right decision” and those who were fired for being wrong. More than likely, those who were rewarded had weighed the pros and cons of the situation and had become thoroughly informed before deciding on the venture.
Making informed decisions is the dilemma at the heart of assessing potential project hazards. It plagues the project manager whose sponsor requests that he or she prepare an assessment of potential project hazards for the statement of work.
How does a project manager go about making informed decisions concerning potential external project hazards? By going out and talking to as many people as possible who have knowledge of every conceivable aspect of the project—and by gathering as much input from them as possible.
Armed with this information, the project manager should be able to formulate key questions for the experts who have the answers. For example, if a project involves building a new atomic power plant, a critical question for a politician from the affected district would be, “Will the government become so environmentally concerned during the construction phase of the plant that they might close us down before we can complete it?” A seismologist could be asked, “What is the earthquake possibility on the land where we propose to build?”
