Practical Project Management – Tips and Techniques – Part 1

Image this scenario: you’re taking over a project that’s in trouble. Money and your firm’s reputation are at stake. Practical project management techniques can make a difference when the heat is on.

Eventually in your career, you will hear the dreaded words from your manager, “I would like you to take over this little project that is having some trouble… .” Most engineers are responsible for a project at some point in their careers. All engineers are project team members for most of their careers. And yet with all of this experience, many find project management difficult–particularly when information technology (IT) is involved.

So what do you do when you’re appointed project manager? This first article in a series of two will help you get over the three hurdles of project management: defining the scope, setting and managing timelines, and managing deliverables.

Defining the scope

The first step in managing a project is to define what it is you are trying to deliver. You’ll need to find answers to such questions as: What is the scope of the system being built or installed? What are the deliverables? Who is doing the training? Who is responsible for implementation into production? What do phrases such as “it has to be done quickly” really mean?

If you are inheriting someone else’s project, chances are that no one will agree on the scope. Sorting this out and getting agreement can be an enormous challenge. Once you have agreement on the scope, put it in writing, circulate copies to all appropriate parties and have them sign off on it, so you have proof that they agreed to it.

In defining the scope of your project, remember that there are three related project variables: time, cost and functionality. You can have X functionality at Y cost in Z time. Agreement on scope is agreement on the relationships among the variables. Being prepared to talk about functionality, time and cost with project authorities will help you hammer out the “real scope.”

Some project management experts like to use the concept of “triage” to define a project’s scope—a term you may recognize from medical shows like ER and the old MASH series. Triage involves the concept of maximum benefit. For example, when doing triage, doctors might pass over a person with a flesh wound and a person who cannot be saved, in order to save the lives of three other patients.

In the development industry, triage translates into asking: How quickly can we get something of value to the users, and what are the highest priority items that are achievable quickly? Arrange the order of your project deliverables using this concept. Then, if the deadline is approaching and it won’t be possible to provide all of the requested functions in the first release, you will know that you can at least deliver something that provides value to a client. Often in projects, the triage concept is applied after the project is already in trouble. Use it early, and your project may never get to the trouble stage.

Controlling change

Inevitably, your project’s scope and requirements will change in some way—either because you understand them better or the key players change. This is not necessarily a bad thing, as long as you manage and track the changes in the project’s scope. This is a critical point. Change control is scope control. The scope defines the project. So if you don’t control change, your project will be out of control!

Probably the biggest mistake you can make as a project manager is to allow change requests from clients or your employer to go unchallenged. At the very least, you should ask project sponsors for a signed change request, so they realize that they must decide what they need and that, if they change their minds, the project’s cost and completion time will increase.

Setting timelines you can live with

All projects I have worked on that were even close to being on time had one thing in common: Every project team member had a copy of the schedule hanging in their cubicles, with dates for deliverables. The fewer the people who have schedule information, the less likely it is that the schedule will be met. Make sure that you also convey any concerns about the feasibility of the schedule to the project team. They will either ease your fears or, if necessary, put in the extra effort required to get the project on track.

How do you create a project schedule? For a short-term project with people who know the tasks well, a schedule may be as simple as a list of deliverables and dates. On large projects, it should be a Gantt chart or other timeline from such project management software as Microsoft Project or Project Workbench. Be sure to include in your schedule the list of tasks, the deliverables created by the tasks, who will do the work, and when it will be done.

There are many elements that must be considered in determining the schedule, including the tasks and length of time required to complete them, the relationships among tasks and staffing levels. Knowing the relationships among the tasks will enable you to decide the order in which they must be completed. For example, in software development, you must have at least some code written before beginning testing. You also cannot complete training material until the design is finalized. The combination of tasks and relationships is referred to as the “work breakdown structure.” On a large project, you should have a senior employee whose full-time job is to manage the schedule and update the work breakdown structure.

When updating the schedule, do not make the mistake most project managers do by asking what percentage of the overall project is complete. We have all heard of projects that were 90 per cent complete for months, before the final 10 per cent was even started. Or the 80/20 rule, where the final 20 per cent of the result takes 80 per cent of the effort. Instead of asking what percentage is complete, ask how much time is required to finish uncompleted tasks, taking into consideration the workload of the person or team responsible.

Finally, make sure you know all of the steps required to move your finished project into production. I worked with a client whose operations department required seven days’ notification before moving new software into production. Exceptions to this rule required senior management approval. Don’t be late because you forgot to send a memo or because operational documentation was not provided.
Bringing it all together

The first two steps—defining your project’s scope and managing its timelines—will set the stage for what you are really trying to do—deliver something. How do you get the agreed upon functionality (the deliverables) into the hands of the people who need it?

Remember that as project manager, there will probably be essential tasks outside of your control, but within the scope required for success. For example, frequently in software development projects, a separate group is responsible for training. You may not have a trainer on your team. Tell the people outside your group what you need from them and when, and tell them early. Get their buy-in in writing. Continue to check on the status of the deliverables outside your control. Escalate any lack of commitment to the appropriate management. Lack of commitment is often the result of conflicting priorities. This can best be sorted out by going to the manager, not the employee, and getting the priorities clarified.

Again, it’s important to review work early and often. You can’t manage deliverables if you don’t know what they are and how they are coming along. Get first-hand knowledge and reports from your team. Review work at all levels of detail. Make sure members of the team review your work before it is distributed outside the group. This will show them that you are serious about having everyone’s work reviewed—including your own. When there is problem, work directly with your team to identify solutions and solve it.

It is also useful to provide regular reminders of upcoming deliverables to help team members manage their deliverables. Upcoming is the key word. There is no point in asking where something is if it is already late. Define clearly what on-time really means. Does ‘on Friday’ mean before the start of the workday on the next Monday or before 5:00pm on Friday? Even little delays can start to add up – particularly if you planned to spend the weekend reviewing a deliverable prior to passing it on.

For project managers, there is a constant struggle between keeping abreast of the “big picture,” and getting mired in the details of each component of the project’s deliverables. When in doubt, dig. It is always better to understand a problem area. If it turns out not to be a problem, then at least you have gained more in-depth knowledge of your system. You can’t truly lead a team unless you are willing to work with them on the smaller details.

When you have met a deliverable, publicize it. Make sure that the people accepting deliverables have seen and approved them, and get their approval in writing. In other words, document that you have met the deliverable.

Words to work by

Time. Money. Functionality. These define projects and are the keys to managing them. If you know where you stand with each of them, you will be on the road to success.

The second article in this project management series will deal with communications and managing the people on your team.

Origianally written by Mark Dymond, IBM

Leave a Reply

captcha *