MCPc Blog

Technology Integration Project Management Process: Define & Design

My last post spoke to the attributes and actions that guarantee a successful technology project, namely, the importance of project planning.  I suggested slowing down to clearly identify the project's goals and objectives — not just the activities — and cautioned against the urge to start building immediately out of the gate.

What happens now that the project is planned? In any major technology integration project, it's important to continue on with your plan in an organized and strategic manner.  At MCPc, we follow a specific project management methodology for all customer engagements in order to keep things organized and moving along at the proper pace.  In this methodology, we move on to the Define and Design phases after the Plan is complete.

Project Definition and Design

The Define phase determines the user, functional, and system requirements for the solution being implemented. After several requirement gathering sessions, we work with the customer to craft a comprehensive, functional specification along with project-specific work documents.  These documents can be line drawings, wiring diagrams or configuration worksheets that offer a visual of the implementation.

Together with the functional specification, these documents become the input for the Design phase and create traceability to the final design and test cases.  Depending on the size and complexity of your project, you should expect the following documents to be created and delivered to you:

• Functional specification (Performance and Regulatory Requirements, Interfaces, Conversions, Extensions, and Reports)
• Project work documents (wiring diagrams, line drawings, etc)
• Product procurement plan
• Updated integrated project plan, complete with major milestones and timelines

The output of the Define phase and approval of the functional specification launch the Design phase.  At this time, we lay out the blueprint of the system — specifically, how it will be designed, configured and tested.  We'll use the project work documents from the Define phase to build the solution design. This final system blueprint is the critical output from the Design Phase.

With these documents in hand, your project manager should elaborate the project structure and schedule and begin to define a comprehensive test plan and corresponding test cases.  A test case defines the conditions against which the solution is tested — a detailed procedure that fully tests all features of the solution.  The test plan describes what to test.

Benefits of a Complete Project Management Process

Much like the Plan phase, it is imperative to diligently gather all solution requirements and create comprehensive design documents in the Define and Design phases.  Following these recommendations will ensure these critical outcomes:

• Your project will have a better chance at coming in on time and on budget.
• The Design documents that outline the technology integration specifications will ultimately become the building block for all test cases.
• Should you wish to implement additional solutions or upgrades down the road, your Design or blueprint will outline exactly what was done and when. 
• The project work documents will offer rationale behind the build.

When embarking upon major technology integration, encourage your team and any external partners to create clear deliverables before the Build phase.  Ask your solutions provider or project manager for their methodology up front, so that you can ensure that these critical components are present in the project management process methodology.

Your thoughts:

• What steps or processes do you insist on completing during the Define and Design phases of your projects?
• What are the key deliverables of your Define and Design phases?

 

Ira Grossman, PMP, is a Director of Project Management at MCPc, and has more than 15 years of technology project management and supply chain experience. Connect with Ira on LinkedIn.

 

Image Credit:

http://farm4.static.flickr.com/3449/3770015203_9cb9aa2188.jpg

Plan Your Projects Like You Plan Your Dinner: Mixing Dinner, IT and Project Management

Would you consider your last dinner party a success?  What is completed on time and on budget?  Did it meet your expectations and those of your stakeholder (i.e. your date, spouse or family)?  

If not, what went wrong? Did you shop too late to get choice selections? Did you even make a list? Did you laminate your plan to protect against a messy counter? (I have actually done this.) Did you forget a key ingredient? Did the presentation resemble the photograph you were attempting to emulate? And finally, did the meal taste as good as the reviews suggested?

Wouldn't it be remarkable if just one thing could ensure a successful dinner, or IT project for that matter? There is, in fact, an often overlooked step that can make or break any project: a well thought-out plan. 

Here, we will examine what steps, precautions, processes, tools and techniques within each project phase are a must to ensure a successful project — success being defined as the proverbial on-time and on-budget, plus achieving the client's business objectives.

At MCPc, we follow a six-step project delivery methodology, so I will use this framework for the discussion. 

 

 

 

In addition, it's important to consider two more steps after project delivery, listed below as steps 7 and 8. 

1. Plan
2. Define
3. Design
4. Build
5. Deploy
6. Close
7. Optimize
8. Steady-State

The importance of Project Planning

So, to continue with the dinner analogy: if you prepared a nice meal recently, how much time did you spend planning it, compared with how long it took to actually prepare the meal?

My last big dinner was for Valentine's Day. I spent hours researching, reading reviews and contemplating alternatives (what would I do if snow prevented me from accessing the grill?) before building my grocery list. This is analogous to the requirements-gathering process for any project.

The way to make a project successful in all aspects is to plan it carefully, not just to start work quickly.

The Plan Phase should identify the scope of the project, define the rules the project will follow and generate a schedule for the major tasks of the project.

And, please don't confuse a project plan with a Gantt chart.

The project plan is the project keystone. It unifies all other management controls and gives the project coherence. Your plan should define:

• Project scope and objectives
• Planning assumptions, constraints, and risks
• Time management and reporting
• Cost management and controls
• Quality management and policy
• Human resource plans and organization
• Communication channels and strategy
• Risk management
• Issues management

The plan phase must contain processes and checks to help ensure that defined goals and objectives — not activities — drive the way a project is managed.  Objectives for the project must be quantifiable, concrete, documented, and accepted before the project team begins work.

Really, the most important aspect of the plan phase is to slow down, and take a thoughtful approach that respects and maintains a project tempo while still carefully crafting the project's quantifiable goals and objectives, as well as other management controls.

I challenge you to try this approach on your next project. Encourage your team to create clear deliverables before launching into the next phase in your delivery methodology.

Your thoughts:

• What steps or processes do you insist on completing during the plan phase of your projects?
• What are the key deliverables of your plan phase?

 

Ira Grossman, PMP, is a Director of Project Management at MCPc, and has more than 15 years of technology project management and supply chain experience. Connect with Ira on LinkedIn.

 

Image Credit: www.conceptdraw.com

 

On-Time and On-Budget — No Longer Good Enough

Author: Ira Grossman

If you have managed a project or have been asked to make a decision about a project for which you are the stakeholder, you likely have considered at least one side of what is known in project management as the Triple Constraint:

 

 

Project managers often invoke the Triple Constraint theory, which simply states that time, cost and scope are related so that if one changes, then another must also change in a defined and predictable way.  At MCPc, we have used this decision-making concept for decades in hopes of completing our projects on-time and on-budget.

Is managing and measuring the Triple Constraint sufficient to determine and drive project success?  After all, the model only considers project delivery as a factor for making decisions and measuring project success.

A New Model Emerges

A new model has recently surfaced, which forces project managers and stakeholders to consider the business value in project decisions- The Value Triple Constraint:

 

The Value Triple Constraint is an evolution of the Triple Constraint. It is a framework for measuring the ongoing value delivered through projects, and for bringing to light the value left behind by the original model.

This change will require that project managers understand the business value that the project intends to provide, and not just the variables that constitute "on-time and on-budget." 

One of the major changes is that the PMBOK® Guide no longer mentions the triple constraint of scope, schedule and cost. Instead it discusses how project managers must balance the constraints of scope, quality, schedule, budget, resources and risk — much more in line with the newer, Value Triple Constraint model.

Project managers: what methodology do you find most helpful when making business decisions?

 

Ira Grossman, PMP, is a Director of Project Management at MCPc, and has more than 15 years of technology project management and supply chain experience. Connect with Ira on LinkedIn.