Preparing Your Project Expedition – Part 2 Project Management Considerations

You will recall, as we left off in Part 1 – Setting the Foundation, we were talking about establishing your project’s goals and expectations in order to chart a course.  We described four basic categories (Project Management, Business, Technology and External Partners) that should be considered when identifying expectations. Here, in Part 2, we are focusing on Project Management and points to consider when defining expectations in regards to this topic. So let’s jump into some of the questions about Project Management Considerations.

Has the organization set any fixed project dates prior to project initiation? Project dates could include the end date of a phase, product implementation timeframes, or any other specific milestone dates.  It is a risk for a date to be set before you know your project’s scope, yet it often happens that an implementation date gets set before the scope of the project is clearly defined.  Your project dates should be set after defining the project scope, planning the work to achieve your objectives, and understanding the vision of how things will look at completion.

Many factors impact a project’s schedule such as project scope, available resources, equipment acquisition, facilities acquisition, budget and outsourcing just to name a few.   You need to consider all of them.  At this stage the project expectations are at a high level and what you need is the detailed information that will allow you to plan specific milestone and delivery dates.  Exact dates will be defined as the project management team scrutinizes each of these areas and their associated deliverables.   

There are unavoidable circumstances that will often define fixed delivery dates such as federal requirements or legislative mandates.  Having an externally defined delivery date before proper planning can impact the quality and cost of a project.  This may also impact the scope of what can be included in the project based on limited timeframes.  You may be able to mitigate the risk by defining a project scope based on the minimum requirements to meet the mandated objective within the available timeframe.

When delivery dates are mandated it is critical to identify key features and minimum requirements during the initial stages of the project.  Those additional features that are not required but “nice to have” features should be captured and planned for future releases.   It is important that project executives commit to the required scope of the project and stay the course; any deviation will potentially jeopardize success for your project.

Does the company have specific project management methodologies, project processes or project tools that will be used? Potential project methodologies include Six Sigma, Waterfall, Agile, ITIL, or hybrid/customized approach.  Project processes may include issue tracking, risk management, change control, and requirements management.  Some available project tools include IBM Rational, MS Team Foundation Server and MS Project.  Employing proven, repeatable project methodologies, processes and tools is critical to project success. Without management and control of the project your success is put at greater risk.  If your organization has pre-established guidelines, then your job may have become easier. 

However, if one of your responsibilities is to establish, or modify, the company’s project management methodologies, processes, or tools then you have now added additional scope to your project responsibilities.  Establishing company project practices adds a huge responsibility to your project.  You will now need to evaluate your own project in addition to taking into consideration the various flavors and complexities of other project compositions within your organization. This will pull your focus off your main objective of delivering your product/service. You will need to account for the resources and time it will take to develop, document, purchase, implement, train and support the organizations new project methodologies, processes and tools. 

Is the product/service to be developed in-house, externally, or some combination of both?  If your organization intends to employ an implementation vendor, will your company allow the project to have off-site or off-shore resources?  This is always an issue for government projects.  Often no utilization of off-shore resources is allowed and there tends to be mixed feelings about allowing off-site resources as well.  There are benefits and risks to having resources on or off site.  Your goal is to determine what will best benefit your project and meet your objectives. The following table illustrates the benefits and risks of utilizing off-site/off-shore resources.

Is this project a “deliverables” or “time & materials” based project?  Time & material contracts are usually utilized when work is performed within an organization and not contracted.  Larger implementations that require outsourcing of services usually utilize a deliverable based model.   This is a decision that is typically made by the organizations executive team. There are pros and cons to both depending on the scope of the project.

A deliverables based project is the typical choice of larger implementations that require an outsourced vendor contract. Specific pay-points are defined for the completed segments of the project. These segments usually have a defined deliverable document that must be approved to officially complete the segment.  Some examples of deliverable documents may include a project management plan, application design documentation, implementation plan, training plan, deployment plan or helpdesk plan.  Deliverable criteria could be additional milestones such as quality assurance testing completed, user acceptance testing completed or rollout of application completed. A deliverable based model provides known costs and eliminates the need to directly monitor reported labor hours. This also places more of the risk on the vendor for delivery of the product/service.

Smaller projects that are resourced with internal resources are usually “time & materials” projects.   Internal resources will often have other full-time responsibilities. Ensuring you understand their project responsibilities and the expected percentage of available time to focus on the new project is important to your schedule.   

Will the project have an independent Quality Assurance (QA) group? A dedicated and independent QA group is a good practice and will improve the quality of the product being developed because they are independent of the development team. This team may be in-house staff or a contracted vendor. It is critical that the role of the QA group be clearly defined at the start of a project. Depending on the QA expectations, different resources and skillsets may be required.  This could even lead to additional deliverables being defined at the start of or throughout the lifecycle of a project.  The following questions are provided as a starting point to think about what expectations this team should have.

• Is the QA group expected to repeat the test scenarios from system test, or are they to write and test their own scenarios?
• Is the QA expected to run automated/load testing samples?
• Is the QA expected to review and provide feedback on written deliverables?
• Is the QA expected to monitor, measure, and report statistics on project controls and activities?

Are there any project partners mandated by your organization, state or federal regulation?   There are nuances with every organization and industry. Some industries mandate that projects contain certain oversight in order to be funded and/or certified. Many large government contracts require an Independent Verification & Validation (IV&V) vendor to receive federal funding.  Some State projects require legislative oversight.  Including additional groups on a project adds a level of complexity and cost to any project.  Additional contract monitoring and accounting, deliverable review (i.e. plans and reports), and resource consumption to work with and respond to these partners adds time and effort to any project.  Understanding the purpose of these project partners and factoring their effect on the project must be included in the initial planning and overall management of the project.

Does the organization have guidelines for deliverable reviews?  This is an important factor that often gets overlooked or downplayed on most projects.  A projects main focus is often on the product/service development component and little time is spent contemplating the overhead of deliverable review.  Be it user guides, design specs, or management plans, all deliverables must be reviewed for content and quality.  Review takes time and resources; especially if there are multiple iterations for each deliverable.

It may benefit your organization to maintain an internal prioritization of deliverable documents based on necessity and quality. You may need to limit what documents get a detailed review and what documents may require less review when time is limited.  Do not interpret this as stating that documentation is not important, but do not sacrifice time and resources for items that provide minimal benefit in the long run. The purpose of document review should also be clearly defined.  All comments on a document should add value to that document.

Are all roles and responsibilities clearly understood and communicated for the project?  Every task defined on the project should be assigned to a specific role as the primary recipient of the deliverable.  This means that the individual assigned is responsible for the reviews, comments and corrections requested on that deliverable. There may be other roles assigned as contributing reviewers, but only one role should be responsible for ensuring the uniformity and final acceptance of a deliverable.  The project manager must trust the staff placed in those roles and hold them accountable to following the processes defined for review and acceptance of deliverables. 

I want to reiterate that these topics are just examples based on experience and “Lessons Learned” and by no means an exhaustive list of questions.  I sincerely hope that these will encourage further thoughts in areas important to your project’s management approach.  Early analysis of your specific project requirements will help you set a solid direction for your project expedition.

Remember, the only constant in life is change and it is never truer than in a project; embrace the concept, plan for its inevitability, and manage it to the success of your project.  Stay tuned for Part 3 – Business Considerations ∆

Resources & References:

“12 Common Project Management Mistakes–and How to Avoid The.” Jennifer Lonoff Schiff. CIO. CXO Media. September 2013. <http://www.cio.com/article/2391872/project-management/12-common-project-management-mistakes–and-how-to-avoid-them.html>

A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Fifth Edition. Project Management Institute (PMI), 2013. Paperback.

“Define project scope to include deliverables, boundaries, and requirements.” Tom Mochal. IT Consultant. Tech Republic. September 2007. <http://www.techrepublic.com/blog/it-consultant/define-project-scope-to-include-deliverables-boundaries-and-requirements/>

“Four Common Reasons Why Projects Fail.” West, Cynthia Ph.D . Project Insight , n.d.  <http://www.projectinsight.net/white-papers/four-common-reasons-why-projects-fail.aspx>.

Project Management Survey Report 2013. KPMG, July 2013. Report. <http://www.kpmg.com/NZ/en/IssuesAndInsights/ArticlesPublications/Documents/KPMG-Project-Management-Survey-2013.pdf>

“Project Management Triangle.” Tutorialspoint.  2014.
<http://www.tutorialspoint.com/management_concepts/project_management_triangle.htm>

“Why Do Big IT Projects Fail So Often?”  Jim Ditmore. InformationWeek, October  2013. <https://owl.english.purdue.edu/owl/resource/747/08/>.

“Why Projects Fail – 101 Common Causes.” Ryder, Greg.  Calleam Consulting Ltd. WordPress, n.d. <http://calleam.com/WTPF/?page_id=2338>.

 “Why Projects Fail – Facts and Figures.” Ryder, Greg.  Calleam Consulting Ltd. WordPress, n.d. <http://calleam.com/WTPF/?page_id=1445>.

*Lessons Learned contributions provided by Michelle LeFeve, Sharon Christman, Sharon Pizzuti and Steve Trudell of Courtland Consulting.