The Value of Using Project Management Techniques in Hi-Tech
Consulting Engagements
by Jim Stewart,
Project Management Consultant and Trainer of JP Stewart Associates
As a former network and systems engineer--and a current practitioner of project management--, I feel uniquely qualified to speak about the value of project management as applied to hi-tech consulting engagements. Strictly speaking, it isn’t absolutely necessary to be a project manager or have Project Management Professional (PMP) status in order to manage an engagement. But it does help to know some of the underlying principles.
Before we continue, one caution: I teach project management and very often people will tell me that the theory is well and good but that in practice, they can’t get some of these processes in place due to customer or team resistance. If that’s the case, that’s fine. You can’t change your customer’s culture overnight. What you can do is work towards the goal of setting a certain standard. If you can discuss with the customer the type of process you would like to see in place--and why--I’ve found that they’ll listen and generally go along. Especially if you’ve already developed a certain level of trust with them.
Scope Definition and Management
In your project, there is nothing as important as defining and protecting the scope. It is very common in projects for the scope to be loosely defined with the idea that it will be fleshed out as the project goes on. In and of itself, that’s fine. The Project Management Institute (PMI) talks about having a preliminary scope statement and then iterating to a more definitive, concrete version. The problem is that some teams never get to the more concrete version. Or even if they do, they have no approved method of making sure that the scope does not change.
So the first tip I’d suggest on any of your projects is to make sure the scope is written down and signed off by the customer. That document (scope statement) then becomes something from which you can work and to which you can refer when the customer goes looking for features that were never promised.
In addition to having a project scope statement, it is advantageous to create a Work Breakdown Structure (WBS) with the project team. PMI defines this as “a deliverableoriented hierarchical decomposition of the work to be executed … to accomplish the project objectives and create the required deliverables.” 1 So, this is a visual that lists all of the deliverables on the project from the highest level down to the lowest manageable components. The beauty of the WBS is that it not only visually portrays the project deliverables but also serves as a good way to obtain team buy-in if created by the team and other stakeholders.
Change control
As you may already know, the difficulty on a project is not necessarily in defining the scope, it’s in maintaining it. In my last full-time job as a program manager, it was not uncommon for someone in management to decide that they needed a new feature after the project was underway. (Usually in response to a customer request). They would then visit the senior engineer, who would run over to see me and ask me what he should do. After this happened a few times, I went to my boss and insisted we institute a change control system. With a change control board in place--consisting of major stakeholders from engineering, operations, and marketing--we could then more dispassionately consider requested scope changes. It was then possible for me as project manager to consult with the engineers and advise management what the proposed change would mean in terms of cost and schedule. As often as not, the proposed change was shelved or delayed until the next revision.
Was this easy to institute? Not by a long shot. Old habits die hard and so marketing kept coming upstairs and trying to make changes outside of the system. But we stuck to our guns in engineering and made sure that everyone in the organization adhered to the change control plan. In the long run, we saved everyone much grief and wound up with a better product (and better-run project).
So if your customer argues with you that you’re not helping them by not allowing changes, you can make a case that you’re helping them in the best possible way – by preventing scope creep, thereby protecting the project.
1. A Guide to the Project Management Body of Knowledge, Third Edition, p. 379. Project Management Institute.
Jim Stewart has been an independent project consultant and instructor since early 2003
and has worked in project management for 15 years. He has managed
several multi-million dollar projects for companies such as Lotus
Development and Genuity and currently teaches at both Brandeis
University and Babson College. He can be reached at
jpstewar@rcn.com or view his website at
http://jpstewartassociates.com/
