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.
Caring Enough to Do It Right
Posted by Brad Egeland
I’m a foster parent who is also an adoptive parent. What that makes me is a foster parent who ‘really’ cares…. a lot. And I have friends who are in the exact same place. I recently ran into a situation that translates very well into frustrations we see in the project management world all the time. It centers around the equivalent to what we all know as requirements.
On one hand you have a biological family who pose a threat – they are safety concern for whatever reason. They have visits with their biological child – that’s their right as parents until a judge says otherwise. You have a visitation center who’s guidelines call a ‘supervised’ visit one thing. On the other hand you have a caseworker who thinks a ‘supervised’ visit means something entirely different – like one-on-one supervision – not fully understanding that a truly ‘supervised’ visit requires a judge’s order. And in the middle you have a foster parent who cares and happens to be the only one who sees and understands the disconnect between the two.
Do you see how this applies? Has this ever happened to you as a project manager or a project team member? You have the customer sponsor, primary stakeholder, or project manager who thinks they need ‘x’. Then, during meetings after kickoff you encounter customer SME’s or end users (many times they are one and the same) who say they need ‘y’. And there you are, the only one in the middle who really sees the disconnect.
You’re either a very concerned foster parent who’s trying to look out for the defenseless life of a small baby or the frustrated project manager who’s trying to look out for the well-being of a project that now appears headed toward a re-work phase where project requirements once thought to be ‘solid’ now need to be revisited. At the very least you have a big project budgeting issue. In the worst case scenario you will experience resource issues, extreme budget problems, task conflicts, timeline issues, and a potential project cancellation as you deal with going back and re-doing some work from the beginning while the project essentially comes to a screeching halt.
Effective Project Presentations
Posted by Brad Egeland
During the course of our projects, we sometimes have the opportunity to give presentations either to our customers or to our executive management staff. This may be a proof of concept presentation, a project kickoff presentation, or a presentation to startup a new phase of the project. Whether you are a project manager or team member, as a presenter it’s a good idea to must follow six fundamental steps:
Know yourself and the audience
Find out about the audience to ascertain your commonalities and differences. You can get useful information, for example, by interviewing people who know audience members. Follow up by making a list of what you share and don’t share with the audience. This knowledge will prove useful in preparing the presentation.
Perceive your audience and how it perceives you
Look at ways to influence the audience to see you in a favorable light. This will make it easier to communicate your message. You can win the audience over, for example, by expressing values or experiences you share with its members.
Determine the type and structure of the presentation
Answer all the who, what, when, where, and why questions pertaining to your topic. Determine if your presentation is meant to inform, persuade, or explain. Then formulate your overall strategy to achieve the goal of your presentation, and your tactics for executing that strategy. If you are able to anticipate most of the questions in advance, then you won’t be blindsided by questions that can torpedo your presentation. The more knowledgeable you sound, the more successful your presentation will be.
Develop the material
Build your presentation. Determine the content and logically arrange it. For example, you can arrange topics chronologically or by level of importance. Also incorporate visual aids, statistics, and other materials. When prepare for something like a project kickoff, base the order of your presentation and the information contained within on some common high-level document, such as the Statement of Work.
Four Principles to Guide Project Managers – Part 2
Posted by Brad Egeland
In Part 2 of this topic we’ll look at the final two of four principles that I’ve selected to discuss for guiding project managers on their engagements. Again, it’s not an end-all list – there are tens if not hundreds of other principles that could be addressed. I would gladly welcome your feedback and input through comments on this article.
Anticipate the Problems that Will Inevitably Arise
Problems will arise on your projects. In the history of all projects, I doubt there has ever been a problem-free one – there are always at least minor issues that come to light requiring some change or action to keep the engagement on course.
The tighter your budget and time frames, or the more intricate the involvement of the project team, the greater the probability that problems will arise. While the uniqueness of your project may foreshadow the emergence of unforeseen problems, inevitably many of the problems that you will experience are somewhat predictable. These include, but are not limited to:
- Missing interim milestones
- Having resources taken away in mid-project
- Having one or more project team members who are not up to the tasks assigned
- Having the project objectives altered at some point
- Having phases of the schedule moved around resulting in changes to project resource requirements
- Falling behind schedule
- Running over budget
- Learning about a hidden project agenda halfway into the project
- Losing steam, motivation, or momentum
Be as Flexible as Possible
Dig deeply to find the facts in situations. If your project involves something that requires direct interaction with your company’s clients, and you erroneously believe that you know exactly what the clients want, you may be headed for major problems. Change is inevitable on the project – whether it’s a major change in direction or a small change in schedule or a minor requirement.
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.
