| fe inputs - .
1. Performance measurement documentation
2. Documentation of the product oi the project
3. Other project records
1, Performance reporting
1. Project archives 2: Formal acceptance j 3. Lessons learned
Any loose ends are tied, and the project is essentially 'closed'. Although many team members are leaving the project, or maybe even have already left, the PM should get input from each of them on the lessons learned during the project, in order to help the next team to avoid the problems that this one faced. The intent is one of helping future projects - not to cast blame on the current team or team members. So this should be done in a positive way.
All project results must be collected and included in the documentation. If this was not done as the project was underway, it can take considerable time at the end. So it is always best to collect as much as possible, and keep it well organized, as the project proceeds, to prevent loss or contamination of information. Then the closure can run smoothly, the team will look professional, and future project teams can benefit.
Chapter 16 ENGINEERING
Engineers can be involved in any aspect of project management and the project team. The primary role of the engineer is generally that of the team member responsible for the technical components of the product or service development. But frequently the project manager also comes from engineering. It is hard to imagine a telecom project that does not have engineering involvement, almost certainly using a technical prime, and probably also using engineers in other roles as well, such as project management or marketing.
The Engineering Role
Engineering departments are the home for many types of technical skills, and these skills are in high demand for telecom projects, since most telecom project are highly technical. This includes hardware and software skills, from design to building and testing. Engineering will ensure that definition; design and development are structured to produce the best possible results
Many engineers love their work, and enjoy having their technical skills appreciated. This makes them good candidates for working on projects, as the project teams generally appreciate having someone to provide the technical expertise. For some engineers, though, projects can be a challenge. In engineering, maybe more so than in other disciplines, there are people who are generalists, and people who are specialists. Projects are a good environment for generalists, because team members should be aware of, and have a good understanding of, the full projects - its scope, goals, objectives, timeframes, etc. Many times team members are called upon to assist others, when the work loadings do not match the staff availabilities. If one person is too heavily loaded, while another is too lightly loaded, the project benefits from having people share the load. With highly technical work, this can be difficult, if the assister does not have the required skills. It is often possible for an unskilled person to assist with technical tasks, but not all engineers have the ability to segregate their work to allow someone without the relevant skills to assist. And as with many functions, it can take more time and effort to break up the work, and show someone how to assist than it would have taken to just do the work. Schedule slips associated with engineering tasks are therefore very difficult to recover. On the other hand, the engineer might well be asked to assist others with their work. To a specialist who prefers working in his own area, this can be quite disconcerting. Many will accept this 'problem' occasionally, but people who have a strong preference for working in their own field sometimes avoid projects because they do not at all enjoy doing other work. To many engineers, this other work seems to be a waste of their time and skills. And, for an engineer who has a niche skill which is needed on many projects, projects become somewhat of a threat because they interfere with his opportunity to develop new skills, or even keep his own skill current. Project teams should keep this in mind. Whereas in some areas just using skills is enough to reinforce them, in technical fields, technologies are rapidly changing, and those working in these fields need to have training, and/or the opportunity to work with the newer technologies in order to keep their skills current.
In addition to having strong technical skills, many engineers also demonstrate strong management skills. Such people are very useful resources for projects, often even as project managers. If the engineer has both the skill and the interest to manage projects, using him as a project manager is a very good idea. Before this is done though, it would be wise to provide PM training, so that he can use the proper PM techniques. It is surprising how many companies take people with good management skills and expect that to manage projects well, without giving them any related training. While it is true that good management skills are required for PM, and that these skills will enable the PM to do much of the work well, it stands to reason that with the appropriate PM knowledge, tools and skills, the results should be better, and the work should be easier to accomplish. Possessing the abilities does not automatically give a person the knowledge and skills.
The other issue that should be considered is the interest of the engineer. The fact that an engineer has demonstrated good management skills does not mean that he is interested in doing a job that is essentially a management job, as opposed to a technical one. I have been approached by engineers wondering what they need to do to be able to get back to doing "real work", when their companies keep pulling them off to manage projects. It is the responsibility of the engineer to identify that he really isn't interested, as the management probably think that they are giving him a reward by allowing him to manage projects. But not everyone is interested in this sort of work.
As mentioned, technical background is needed on most telecom projects. The environment is by nature a technical one. However, in addition to the advantages of engineers' having technical background, there are also some dangers in this. First, the engineer might be assigned a dual role, of both project technical expert and project manager. This frequently happens on smaller projects where the workload of each position may not require a full person. In this case either the team is staffed by people who are also assigned to other work, or some people play double roles. For many, this is an interesting challenge, because it offers the opportunity to use two sets of skills and to see the project from two different perspectives. For others it is a problem. Some personality types need to work within a defined environment, and a dual role can be more than the usual challenge for this type of person.
In addition, the dual role can place the holder into a compromising position from time to time. There are bound to be occasions when decisions must be made which involve the technical aspects of the project. Sometimes the best decision from a project management perspective is to move in one direction, while from a technical perspective the best decision would be to move in a different direction. Even when the engineer is not placed in a dual role, but in just the PM role, this same type of situation can occur, and the engineer who is loyal to his field, or who would strongly prefer to be doing the technical job, is in a very difficult position, with a tough decision to make. Given that the project manager views the project from a broader perspective, the PM direction is usually the right one to take. But this is very hard for the engineer, who might even be viewed by his peers as selling out.
Engineers must take great care to ensure that they are acting in the best interests of the project overall, while still holding to their ethical convictions, and ensuring that the best technologies and designs are used.
This page intentionally left blank
Chapter 17 OPERATIONS
Many projects in the telecom environment are operations projects. Most projects require some involvement from operations organizations, even if they are not centrally operations projects. In the telecom industry, "operations" encompasses many diverse functions, and often aspects of many such systems are needed. These aspects impact the product at different times during the product life cycle, so operations people should be involved in determining the aspects of the project lifecycle. The different aspects of project integration are also examined.
In a telephone operating company, the term operations applies to many functions which support a multitude of vastly different functions. On the line side, operations includes taking trouble calls, and testing circuits or equipment to locate troubles. It includes finding and fixing major problems such as fibre cuts or switching centre failures. It includes taking customer orders and maintaining customer profiles and data in databases. In the staff area, operations involves the selection of development of and maintenance of operational equipment such as network management systems, test systems, billing systems, provisioning database systems, order tracking systems, etc.
The operations labour forces are huge, and it's obvious that they are involved with products throughout their life cycle. No matter what the product is, the cost of operating the product is very often greater than the cost of development and building combined. So operational considerations need to be taken into account on all products. Representatives from operations departments should participate in the planning of every project, particularly in the design stages, to ensure that the design can be maintained and supported, hopefully at reasonable cost, over the long term.
In most cases the company will be providing some ongoing support for the product or service being developed. This support will be provided by someone from operations, whether the company is a telco, an internet provider, an equipment vendor, etc. In order to protect the company from high long term costs, or loss of reputation due to the inability to provide proper support, operations should be involved in every project as a team member.
Let's look at the lifecycle concept first. The product has a lifecycle. And also the project has a lifecycle. The two are quite different. Consider the product - maybe a web site, a fast digital switch or the deployment of a network upgrade. The product lifecycle starts with a definition of the requirements, followed by the product design. Once the design is complete the product is built, and then the support phase begins. The product lifecycle thus consists of four phases: Requirements Definition, Design, Build and Operate/Support. This is never the same as the project lifecycle. The project might occur within one of these phases, it might be one of the phases, or it might span a few of the product lifecycle phases.
Operations concerns often relate to the time period after the project completes. However, even in such projects operations involvement is needed early to ensure the development of a product which can be effectively maintained. Also in a telecom environment, many projects produce operations deliverables, such as new processes or systems. In these cases operation involvement is required to design and develop the product. Someone from operations might possibly also be the PM.
The project lifecycle starts at the point at which an idea is generated that might be considered as a project. It shows the project from the initial concept stage till full closure. The lifecycle shows the project divided into project phases. Generally it is also marked with flags for gates or indications for milestones
A sample of a project lifecycle is shown in Figure 2. This sample illustrates the lifecycle by plotting the number of resources used against time. The cycle could also be plotted as number of work hours over time, or cost over time. Sometimes these three would yield the same pattern, but sometimes these would differ from each other.
Another lifecycle sample is shown in Figure 3.
This illustration includes more detail showing possible project milestones.
A project could occur at any point within the product lifecycle. However, the project will have a defined end date, by which certain specified deliverables will be produced. The project lifecycle ends when the deliverables have been completed, and the project closure activities are finished. Unless the purpose of the project is to close down the product, the project will end before the product. Figure 4 shows some possible places that projects might occur during the life of a project.
Consider the example of a fairly major project, such as the development and market launch of a new service. This could be shown as shown here.
Note that the last box, service support, is smaller than the others. This was done to show that this segment occurs after the end of the project. In all likelihood, in fact, the chain shown here would consist of multiple projects, as illustrated by the diagram. When that is the case, we have a program of related projects, and each succeeding project is dependent on the completion and scope delivery of the previous one. Another example of a program could be the development of a service or product in stages, where an initial set of features and/or functionality is developed in the first project, then enhancements and additional features are added in the succeeding projects. The interdependence is obvious.
Each project has a lifecycle, and each is different. The team needs to determine what the lifecycle of the project will look like. The PM will need to know this to determine the resource requirements. The lifecycle will give an indication of the pattern and timing required for the project cash flow, and it can be used as an illustrative communications tool to communicate the flow of the project.
As mentioned, each project is broken into phases. What is recommended from a PM perspective is that the overall project follow a standard lifecycle, with four phases -concept or initiation, planning and definition, implementation and closure. During the implementation phase, the project can then be broken up into whatever number of product phases makes sense. These are mini phases within the one larger product. Each of these sub-projects should then have its own four project phases - concept or initiation, planning and definition, implementation and completion phases. But they are still components of the larger project. In some cases these smaller phases might have different team leaders, but the overall project manager is accountable for all components of the overriding project.
The short concept or initiation phase, is the point at which the idea for the opportunity or the problem solution is assessed and determined to be something that is worth pursuing. The level of involvement is usually very low at this stage because it would not make sense to use many corporate resources until a decision is made to move ahead. The decision taken at this point should be to move forward, but it should be conditional on the results of the next planning or definition phase. As long as the project continues to look viable at the end of the second phase, it will be worth allocating resources to completing it. This does not mean that this initial decision should be taken lightly, because corporate resources are used to complete the second phase, and as the diagrams show, generally the level of involvement, and hence the cost, starts to grow significantly at this point. This initial phase is used provide the information required to obtain approval and sign off on the concept. In this phase the participants evaluate the concept to determine whether or not it is a good idea for the company to invest resources into the project. The team should make a recommendation, and the management or customer should make the go/ no go decision.
The Planning or Definition phase is used to expand the project concept. Product/service developers and other project team members work together to define what will be produced, and develop the project plan. If this phase is completed properly, the end result will be a complete project plan, with a full scope definition, complete with all the details down to the activity level, a detailed project budget, defined resource allocations, quality standards defined, a risk management plan developed, a complete project schedule, a communications plan, and a procurement plan. In other words, the complete development of the project plan occurs here. We need to have involvement from all parties related to the project and the final product in order to accurately determine the details for the plan. Thus if this is done properly, there is a significant cost involved. But then, in exchange for funding this work, management has a right to expect that they will be provided with prediction of the time and funding required to complete the full project. Each company establishes their own tolerance limits for the information provided at these gates. At the end of the concept phase the budget and time forecasts might be accurate to within plus or minus 100%. But the planning phase should produce information that is closer to 10% accurate. Some companies require 5% accuracy at this point. The management then has a right to expect that the project team will produce the defined deliverables within 10% of the provided budget and timelines. So the team should work diligently to ensure that these projections are as accurate as possible.
Implementation includes the development work required to produce the desired outcome. Here the project manager introduces control and management to hold the team to the predictions for budget and time that were developed in the planning phase. The team responsibility is to do the work as carefully as possible, and to ensure that all required communication flows according to plan. This can mean that bad news is communicated early, but that communication might just enable the determination of some creative solutions to the problem. At the very least it can allow the impacted parties to adjust to accommodate the problem.
Since some projects have phases related to the context within the implementation phase, there will be some additional time required within the implementation phase to work on these sub-phases. For each of these it is wise to do additional definition and termination phases. That will ensure that nothing is forgotten or missed in the early stages which might cause delays or additional work at the later phases, and allow the team to switch to contingency plans if needed due to problems early in the project. It will also ensure that project documentation is not lost or forgotten as people move on to subsequent work.
Termination includes completing all project management work, as well as obtaining closure from the client and management for all requirements. It is during this phase that the handoff generally occurs. Probably shortly after the project enters the termination phase, the project team will hand off the product to the customer or the department that provides ongoing service and maintenance. This receiving group must agree to accept the product, so the project can close. To achieve this, a hand-off document should be developed, which can be signed off when all parties are satisfied. This hand-off document should be prepared in the definition phase, and all involved parties should agree to the contents and requirement levels before the implementation begins. Doing this will prevent the project deliverables from being thrown back 'over the wall' in the final stages. It does not mean that there will be no discussion about whether the project deliverables have been satisfactorily completed. But it will provide a frame of reference for these discussions, since all parties have previously signed off on the requirements for a successful handoff. In this phase all project documentation is completed. Hopefully most documentation has been kept up to date during the project, so that the work effort at this time is minimized. This is critical since many project team members abandon ship by this point, moving on to the next exciting project. Even though people are leaving, lessons learned need to be documented and communicated so that they can be used on future projects, contracts have to be closed out, plans and minutes need to be filed for future reference, the change request documentation must be completed, showing the actual results of each request, user documentation needs to be completed and shared, training of support staff must be completed, etc. There are many activities that must be completed, albeit many of them administrative. The project cannot completely end until these are all completed.
The life cycle diagram shows the project flow from beginning to end. A simple form of life cycle plots the effort, or maybe the number of resources, over time. Then the gates that are to be passed can be added at the appropriate times. One of the early gates might be project approval, and one of the later gates could be product acceptance. And there will be specific criteria that must be met in order for the project to pass each gate. For the product acceptance, these are defined in the handoff document. The criteria for the early gates need to be defined in the early project documentation. In fact, each of the early gates could be a point at which the project may die. If the criteria required for project success cannot be met, the project should not proceed. So we can say that these gates, or evaluation points, are critical points within the project life cycle.
When the project work begins, it is critical that each of the phases proceeds independently of the others. That is to say that work which belongs in any one phase should be completed when the project is in that phase. Any overlap between phases increases the risk of the project. For example, suppose that during the concept phase a project which requires major changes to the billing structure looks like a corporate necessity in order to maintain major customers who might move to a new service about to be introduced by a major competitor, which uses a more flexible billing structure measured by different parameters than the current billing system uses. One way to implement such a service could be to make major changes to the current billing system. Another solution could be to implement a new billing system for the new service. If this were to happen, either the new system would have to replace or be integrated with the current system, or any subscribing to the new service as well as existing services would receive two separate bills - never a popular situation with customers. Suppose that it was decided that the current system had already been modified too many times to make another such addition feasible, so the new service would initially be introduced with a separate billing system until such time as a separate operations project could find a better solution. Also, given the timing of the competitors service introduction, it was deemed that an RFQ would have to be issued for the new system because there was not time to develop one in house. In fact, even if the RFQ had already been issued, there was probably not enough time to have the system in place before the required service launch. So, specifications were drawn up as carefully as time allowed, and the RFQ was issued. Then in the planning phase the service implementation is changed in such a way that the new billing system is not needed. However since the RFQ had been issued, responses received, and evaluation almost completed prior to this decision, they were costs for getting out of the purchase, over and above those of just the internal time to issue the RFP and evaluate the responses. In essence, issuing the RFQ is work that belongs in the implementation phase. Not in the concept or even the planning phase. So having it happen too early increases the risk of the project.
Longer term operations concerns
Since a significant percentage (over 50% by most studies) of the overall cost of any product or service occurs after the product development, operations concerns have a very major impact on the corporation providing the product or service, and also on the customers. From the project management point of view there will be many decision points in the product design and implementation at which there will be a 'right' decision from the perspective of the cost of completing the project. This 'right' decision is often not a good direction for the long term: the product operating cost may turn out to be much higher than it could have been if the project had taken a direction that cost more money during the project implementation phase. In most cases an operations perspective is needed to identify this pitfall, and to work with the project team to make the best overall decision.
Such decisions usually take the form of seemingly harmless compromises in the scope or quality of project deliverables. A simple and common example from the telephone industry might be the development of a new suite of OSS (Operations Support Systems) features for the control of the switching network. Developers might be faced with a decision whether or not to buy an unlimited use license for a block of third-party software for inclusion into the system. If the budget is getting tight, "penny wisdom" might call for forgoing paying this one-time fee. The resultant "pound-foolishness" however, is that the operating company will have to pay per-site license fees in perpetuity for the use of this software in the completed product. There was a project cost saving, and there was no difference in the features of the completed system, but did the project manager really do the right thing?
This page intentionally left blank
Chapter 18 PURCHASING
Recall the full procurement cycle includes:
■ Procurement planning - determining what to procure and when
Solicitation planning - documenting product requirements and identifying potential sources
Solicitation - obtaining quotations, bids, offers, or proposals as appropriate
Source selection - choosing from among potential sellers Contract administration - managing the relationship with the dealer Contract close-out - completion and settlement of the contract, including resolution of any open terms
The Purchasing Department is often not intimately involved with projects, which is surprising considering the potential impact of purchasing activities. The PM should ensure that purchasing is brought into the project early. He should also ensure that he can work well with this department to take advantage of their knowledge and skills.
In a projectized company, sometimes purchasing departments do not even exist. In this case, the project team must perform this function. The information in Chapter 6 should be considered seriously and the legal department should be consulted.
Contract Close out
In the final stage the team closes the contract by:
• verifying that the product or service meets the specifications or requirements, and if necessary, following up with the vendor re any gaps or missing material.
documenting all aspects of contract management and vendor management
• auditing the product/ service provision to ensure that everything was handled properly, and evaluating the supplier and the relationship, as input to further teams or individuals who might deal with this supplier in the future.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.