Implementation Preparation

As the delivery team plans for deployment, or implementation – depending on what you prefer to call it, there is much preparation that must occur. How you prepare for your particular project depends on several things including the following:

• Customer requirements
• Type of system being implemented
• Policies and processes of your organization
• Logistics of customer, delivery organization, and implementation site

Personally, the type of implementation prep that I go through with my team is dictated heavily by the needs of the specific implementation and what was planned for and laid out as part of the statement of work and the kickoff sessions with the customer.

In his book “Project Management Nation,” Jason Charvat discusses his vision of typical implementation planning and preparation. While I don’t specifically endorse this process and understand that your specific situation usually dictates how implementation is handled, I believe that this is helpful and useful information.

Implementation Checklist

The project manager must be sure that the implementation follows the implementation tasks and activities as stated in the project schedule. This forms the basis against which the implementation will be done. Generally, the tasks would be to:

• Load or install the new system
• Perform a system test
• Convert to the new system
• Verify that an application works with other applications in the system
• Perform an integration test
• Perform an acceptance test

The Implementation Plan

The implementation plan, which was developed by the project manager during the design phase, should, at this stage, be approved and communicated to all project stakeholders. A successful project can be ruined by a poor implementation plan. A working implementation schedule should be developed and maintained for all parties to use and agree upon. As the project changes, the project manager must pay close attention to the schedule and update it to reflect the latest changes to the implementation date. This schedule should then be communicated to all project stakeholders.

It is important to publish an initial implementation schedule for each site early in the project. Many members of the deployment project team will reach a point where they cannot until they know the time, sequence, or date of the implementation. Experience has shown that developing a draft implementation schedule early in the project life, rather than later, resolves many problems. The project manager should remember that the implementation plan could be put on hold if the software development is late for whatever reason. However, if the implementation plan cannot be moved and there is no slack in the schedule, the project manager should immediately escalate this risk to the necessary stakeholders.

Meetings Leading up to Implementation

The implementation plan must be discussed and agreed upon by both the user management and IT support staff in order to ensure that both parties plan their work schedules to match the project schedule. For the majority of IT projects, implementation will most likely occur after hours or over weekends, during a series of working hours per day, or on public holidays.

The IT Auditor’s Role in the Software Development Process

In further examining the IT Auditor’s role in the IT project environment, I’d like to look at how the book “Information Technology Control and Audit” discusses the IT Auditor’s role in the overall software development process.

Software Development Process

A formal systems development process provides an environment that is conducive to successful systems development. This includes: (1) an information systems strategy that guides developers in building systems that are consistent with the organization’s technical and operational goals, (2) standards that guide in the selection of hardware, software, and developing new systems, (3) policies and procedures that support the organization’s goals and objectives, and (4) project management that ensures projects are completed on time and within budget. Auditors can assist organizations by reviewing the systems development process to ensure that developed systems comply with the organization’s strategy and standards.

Software Development Phases

The systems development process can be broken down into four phases:

• Planning
• Development
• Implementation
• Maintenance

The planning phase sets the stage for the success of the development effort. If not done properly, the budget and schedule may not be sufficient, the problem may not be adequately defined, the final project may not solve the business problem, and the right people may not be involved. The planning phase of systems development includes the following activities:

• Needs analysis: a study to determine whether a new system should be developed
• Current system review: a study of the current system to identify existing processes and procedures that will continue in the new system
• Conceptual design: preparation of the proposed system flow and other information illustrating how the new system will operate
• Equipment requirements: hardware configuration needed to process and use the new systems (e.g., processing speed, storage space, and transmission media)
• Cost/bene?t analysis: detailed financial analysis of the cost to develop and operate the new system, the savings or additional expense, and the return on investment
• Project team formation: identify people from programming, user departments, and support departments to develop and implement the new system
• Project plan: an overall project plan with defined tasks and deliverables to monitor actual results and ensure successful progress

Auditing can be involved in the planning process to develop an understanding of the proposed system, make sure time is built into the schedule to adequately define controls, and verify that all the right people are involved.

There is a definite correlation between a well-managed systems development process and a successful system. The use of a proven system development methodology increases the probability that the system’s internal controls will be effective and reliable. As discussed under the traditional development approach, systems development includes the following phases:

• Analysis: Define what is required of the new system.
• Design: Define how to build the new system to satisfy the requirements.
• Construction: Build the new system using the design information.
• Testing: Verify that the completed system meets the users’ needs and functions without fault.
• Implementation: Deliver the completed system to the end users; obtain satisfactory feedback.
• Maintenance: Modify the system as needed to correct problems or meet changing needs.

Auditing can review the development process to ensure the software is designed with user requirements documented, that management approves the design, and that the application is tested before implementation. An additional focus is ensuring that the end user is able to use the system based on a combination of skills and supporting documentation.

Don’t Kill Your Customer – It’s Bad for Business

Whether you are a project manager working in a large corporation with a PMO, or a PM-inclined individual in a smaller company thrown into the PM role, or a skilled consultant recruited by any sized organization to lead critical initiatives, you’re going to run into customers who drive you absolutely crazy.

I’ve discussed in previous articles some negative things about customers. These aren’t surprises to the experienced IT veteran. Usually the customer does not have the necessary expertise or knowledge that is needed – otherwise they wouldn’t be customer and they wouldn’t be coming to us for their project. Whatever it is – there is some need and they’ve come to you specifically, or your company in general, to fill that need.

If you come from a software development background then you know the attitude I’m talking about. It’s easy to put yourself above the customer and talk down to them. You need to both avoid coming across as knowing more than they do while at the same time resisting the urge to throttle them when they can’t seem to get a grip on what it is they really need and what you’re trying to do for them.

Customer Service

While customer service may not really be in the job description of most software developers and other key members of your project delivery team, it is a key responsibility of the project manager. The PM is the face of the company to the customer and the first point of contact for issue resolution during the project engagement process…and sometimes for a period of time following deployment. How you respond to that customer may mean the difference between ongoing revenue from them in the form of add-on business and change orders and a work stoppage on a project if they feel like they’re being treated like second-class citizens.

An Example of Bad Customer Service

I had one customer where my team was performing an enterprise software application configuration and rollout. It was, of course, one of five or six projects I was running at the time and one of three or four projects that most of my team members were involved with also. I had a junior business analyst on the project and a senior business analyst – supposedly the junior was being mentored by the senior. What actually was happening, though, was all the work being performed by the junior and no oversight by the senior.

What resulted was a functional design document that was full of errors – even easy typos – and it took four or five iterations to get it cleared up. At that time, peer reviews of documents like that were performed by position peers – meaning the senior BA was supposedly reviewing the document…but that never happened. Policy changes following this fiasco meant that peer reviews were performed by the whole team (something I personally should have required anyway as the PM…lesson learned, definitely).

What the customer saw, however, was a bad document being delivered to them repeatedly and they then realized that the senior BA was too busy with other critical work to be involved in the project. They actually had to state that they felt like they were being treated as a second-class project. Wow…I ended up with a lot of damage control on my hands.

The Lesson

The lesson here is to be proactive when these situations arise and correct the problem before the customer feels that they’re not high on your priority list. They know you have other work to do, just don’t make them feel like they’re at the end of your list. Your customer came to you out of need and because they lack the skills, resources and probably time to perform what you and your team can perform for them. Understand their need, work with their weaknesses and help them to fully understand the solution. You’ll end up with a very satisfied customer and likely a long-term customer.

Phases of a Construction Project Life Cycle – Part 2

In Part 2 we’ll continue to look at the phases of a construction project as laid out in F. Lawrence Bennett’s book entitled “The Management of Construction – A Project Lifecycle Approach.” In this article, we’ll see how Mr. Bennett desribes the pre-project, planning, and design phases.

As I’ve already mentioned, I find this interesting as my experience has been almost exclusively with software development projects. If any of our PM readers are in the construction industry, I’d enjoy hearing your feedback and perspective.

Pre-project phase

A construction project begins with an idea, a perceived need, a desire to improve or add to productive capacity or the wish for more efficient provision of some public service. Whether the idea will be converted into a completed project will be decided during the planning and design phase. However, prior to that, among the first things the owner must do is to decide what sort of project delivery system will be used. How will the various parties be related? Will the owner engage a design professional to prepare plans and specifications and then contract separately with a construction contractor? Or, will a single entity be responsible for the entire project? Other possible options include several separate specialty contractors, each related by contract with the owner, the use of a construction manager as an advisor to the owner, the use of the owner’s own construction forces and the phasing of the project such that individual portions of the field work are commenced prior to the completion of all design work.

The other primary decision required by the owner early in the project relates to the type of contract to be used with the contractor. Will the contractor be paid a specified fixed price, regardless of the actual quantities used in the project and regardless of the contractor’s actual costs? Will the quantities of materials be measured and the contractor paid on the basis of those quantities and pre-agreed-upon unit prices for each material? Or, will the contractor be reimbursed for its actual costs, plus a fee, perhaps with an agreed-upon upper limit? The owner will also need to decide the basis upon which the design professional will be paid. Often these decisions are not made without consultation and advice. Depending upon the owner’s expertise and experience in administering construction contracts, the owner may engage a professional engineer, an architect or a project manager during this pre-project phase to advise on these important decisions.

Planning and design phase

The project is fully defined and made ready for contractor selection and deployment during the planning and design phase. It is convenient to divide this phase into three stages. The goal of the first stage is to define the project’s objectives, consider alternative ways to attain those objectives and ascertain whether the project is financially feasible. In this process of planning and feasibility study, a project brief will be developed, more details will be set forth in a program statement, various sites may be investigated, public input may be sought, a preliminary cost estimate will be prepared, funding sources will be identified and a final decision on whether to proceed with the project will be rendered.

In the second stage, the design professional will use the results of the planning efforts to develop schematic diagrams showing the relationships among the various project components, followed by detailed design of the structural, electrical and other systems. This latter activity is the classical hard core engineering familiar to students in the design professions, in which various engineering principles are used to estimate loads and other requirements, select materials, determine component sizes and configurations and assure that each element is proper in relation to other elements. The output from this design development effort is used in the final stage, wherein contract documents are prepared for use in contractor selection and installation work at the construction site. The design professional prepares not only the detailed construction drawings but also written contract conditions containing legal requirements, technical specifications stipulating the materials and the manner in which they shall be installed and a set of other documents related to the process of selecting the contractor and finalising the contract with the successful tenderer.

Next

In Part 3 we’ll look at Mr. Bennett’s description of the contractor selection and project mobilization phases.

Phases of a Construction Project Life Cycle – Part 1

Having almost exclusively only dealt with and led IT software projects throughout my career, I’ve always been intrigued by the area of construction project management. Though with my background, getting in the door – even on a consulting basis – to gain that experience just hasn’t happened or the timing was just never right – either in the Midwest or in Las Vegas during the housing boom.

So running across F. Lawrence Bennett’s book entitled “The Management of Construction – A Project Lifecycle Approach” peaked my interest. I’ve written about project lifecycle and methodology phases at great lengths in my articles and would like to present here Mr. Bennett’s parallel segments on the construction project lifecycle. Due to the length of the material, this will likely need to be shared over multiple parts starting with his general overview for the purpose of this article. The following text was derived from Mr. Bennett’s Management of Construction book.

Overview

Every project, not just those in the construction industry, goes through a series of identifiable phases, wherein it is ‘born’, it matures, it carries through to old age and it ‘expires’. A software development project manager, for example, might define the following phases in the project’s life cycle: initial proposal, process engineering – requirements analysis, process engineering – specifications, design, development, testing, deployment and support. Likewise, a project that results in the development of a new product might contain the following phases: conceptual, technical feasibility, development, commercial validation and production preparation, full-scale production and product support. Although there may be some overlap in the phases, the work generally flows from the first phase to the last, with the outcome of one phase providing the basis for efforts carried out in the phase that follows.

So it is also with construction projects. We will be identifying six phases in the construction project life cycle, each with its own purposes and characteristics. First, the owner must make certain pre-project decisions. Then the planning and design of the project is carried out. Next, the contractor is selected, after which the contractor mobilizes in order to carry out the field operations. The field work that the lay person often considers to be ‘construction’ can be considered a separate phase. Lastly, the project must be terminated and brought to a close; because these activities are distinct from the installation work, we separate them into a distinct, final phase.

To attempt to understand the management of construction by organizing the study on the basis of the project life cycle may be somewhat arbitrary, because there is admittedly some overlap between phases and thus some duplication in the presentation. However, this deliberate design of this text will provide a logical basis for tracking the project’s activities and understanding the roles of the people responsible for those activities, from the time the owner first conceives the idea for a construction project until that point when the contractor has vacated the site for the final time.

Structured in this way, each section provides a description of one of the project’s phases. The result should be an understanding not only of the importance of each phase individually but also of the way they interrelate to form an integrated whole project.

In Part 2, we will present an overview of each of the six phases of the construction project life cycle.