Running head: High Level Project Plan and Risk Mitigation

High Level Project Plan and Risk Mitigation

Miomir Arandelovic

California Intercontinental University

Doctor of Business Administration Program

IST-635: Managing IT Projects

February 28th. 2016

Faculty: Dr. Ming Luong

Grammarly Plagiarism Score: 12%

 High Level Project Plan and Risk Mitigation

High Level Project Plan and Risk Mitigation

According to the study of Block et al. (2012), which included 5400 large projects, IT

projects on average run 45% over budget, 7% over time and deliver 56% less value than

projected. A percentage of projects that go so badly that threaten the future existence of the

project is 17%. Thus it is of paramount importance for businesses to take measures from the

early phases of the project to clearly project goals, along with risks and possible contingencies.

The topic of this paper is to analyze a process of developing a conceptual project build,

which, at high level defines project deliverables and features, implementation phases, key

milestones and technology infrastructure. Based on the performed analysis, some best practices

for the development of high level project plans would be identified.

Conceptual Build

Kapur (2005) defines Conceptual Build as high-level project plan that addressees the

customer’s requirements. Such plan should define a list of project phases, high-level

deliverables and features, key milestones, and the technology infrastructure needed to solve the

problem and achieve the customer’s business goals. The conceptual build should also make

notes on every known project risk and possible contingency and propose the alternatives

considered for solving the related problem. Possible alternative path in project implementation

should be defined at the high level only, but with possible benefits and weaknesses, even though

the available documentation and references regarding such alternatives should be included in the

appendix. The conceptual build should define the following key elements of the project:

● What the product should accomplish

● What functionality will be included

● Who will use the developed application

 High Level Project Plan and Risk Mitigation

● Where will it the developed application used

Project goal definition is a central element of every project plan. According to Bloch et

al. (2012), the most of the project that experience cost overruns, 13% out of 45% go over budget

because of missed focus. At the stage of conceptual build, project goals should be clearly

defined at business level, along with its priority, but a definition of details should be postponed

till later phases. If we consider an example project that augments the existing ERP system to

allow for enterprise level, multi-project, multi-team project coordination, the goals of such

project would be to develop the system that would allow sharing of idea, information and

resources at enterprise level.

Product functionality is also a crucial element of the conceptual build, as it would detail

the requirements for the developed product. The requirements at the conceptual build stage

should be set at high level, allowing for the technical details to be added at the later stages. In the

aforementioned system, such requirements could include:

● Design of he shared database of current projects at different phases

● Interfaces that allow visibility into project deliverables and technologies utilized

● Communication infrastructure that supports organic information sharing

● Ability to require temporary assistance of the resources at enterprise level

● Reports for the high and middle management regarding project progress

Product audience should be specified as well. It is important to define various modes of

behavior for the product, such as the high management, mid-management, developer and

administrator view of the system. In the aforementioned project coordination system, the

intended audience would include stakeholders, management, system developers and

administrators.
 High Level Project Plan and Risk Mitigation

Key deliverables will be comprised of hardware and software artifacts setup and

activated as a part of the new system. In the aforementioned project, the system should include a

designated in-house or cloud-based shared database, web user interface and set of background

processes that allow communication and reporting, along with the documentation and training

manuals that would offer introduction and online help to the intended product audience. The

explanation of the key deliverables should also include the notion of the utilized technology and

the possible alternative path in the case when the new technologies are introduced.

System access options might include personal desktop and laptop computers, as well as

mobile devices, to allow for the organic communication and information sharing, similar to the

modern social media applications. The Conceptual Build should define high level description of

the type of access provided for the system, such as core user inputs and the information they can

expect to obtain from the system.

How should Conceptual Build Improve the Project Performance

According to Kapur (2005), the conceptual builds should enable control of project

runaway conditions, or jeopardy points, where the costs run over the budget or the project

deliverables and scope stays behind the schedule for the significant time. Important goals of the

conceptual build would be to minimize these jeopardy points, and also to define triggers within

project implementation that indicate possible project runaway conditions.

The Conceptual Build should propose project risk mitigation information is at high level.

Only major milestones might be included at this level, and are to be revised when the detailed

project schedule is created. The high level milestones and timelines are still important as they,

according to De La Cruz (2008):

● Provide basic indicators that tangible progress has been made on the project;
 High Level Project Plan and Risk Mitigation

● Ensure validation allowing the project to move on to the next step if the milestone is

met or take corrective action if the milestone is not met

● Provide support for staff resource planning and budget preparation.

According to Bloch et al (2012), the high level project plans could provide “value

assurance” if it:

Engages all relevant stakeholders which should provide the input to be considered

during implementation, to avoid later feature gaps

The project is implemented as a part of overall corporate strategy, rather than

focusing just on the isolated budget and scheduling

Technology and content that would be used in the project is mastered by ensuring

support of critical internal and external resources

Project team allocated according to the principal skills and interests of the members

Effective project management practices, such as Agile technology is utilized in order

to ensure short delivery cycles and rigorous quality checks

Project leaders continually engage with all business unit and functional heads to ensure genuine

alignment between business needs and the IT solutions being developed. In the projects where

stakeholders, corporate strategy and technology concerns are not taken into account, project is

likely to run over the planned cost, and these conditions are present it in about 50% of the late

projects. (Bloch et al., 2012).

The conditions where the optimal project teams and effective management practices are

not in place contribute to another 40% of the project cost overruns. Adding the additional

resources to the project would often not help achieving targets or deadlines and might just

increase costs, as the relationship between involved efforts and the timelines are not linear. The
 High Level Project Plan and Risk Mitigation

project manager should ensure optimal project team and schedule, rather than trying to meet

business preferences at any cost. The schedule that is shortened to meet a deadline would likely

cause the loss of work efficiency and the product quality. According to Putnam (1997), the

unrealistic schedules are one of the most frequent causes of project failure, and for each project

to be successful; there is very specific relation between project duration and the invested efforts,

as presented on Figure 1 below.

Figure 1. Project success based on invested time and efforts, based on Putnam (1997)

Conclusion

The purpose of the conceptual build of the project plan is to present an insight to a high-

level solution to the customer’s problem, for the stakeholders and future users of the system. As

only the high level information presented at this stage, it makes possible for the stakeholders to

identify potential issues with the project goals and allocated resources and to address them at the

early stage, before a significant investment has already been made. The topics that would be
 High Level Project Plan and Risk Mitigation

discussed between project manager and stakeholders include core project requirements, phases,

high-level deliverables and features, key milestones, and the technology infrastructure. The high

level picture of the project also help identifying possible risks, contingencies, critical paths and

the alternative solutions in the case that a part of the progress development get blocked due to

circumstances hard to estimate in advance (Passenheim, 2009).

If all the right stakeholders are engaged at the phase of the Conceptual Build and it is

ensured that a project will be a part of the general corporate strategy, the studies performed by

McKinleyand Oxford University, that it is much less likely for project to overrun costs. The

engagement of the optimal project team and agreeing upon a feasible schedule would also

address some main of the causes while many projects today are implemented over the budget and

behind the schedule.

 High Level Project Plan and Risk Mitigation

References

Bloch, M., Blumberg, S., Laartz, J. (2012). Delivering large scale IT-projects on time, on budget,

and on value. Retrieved from: http://www.mckinsey.com/business-functions/business-

technology/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-

value.

De La Cruz, F. (2008). Effective Management of Fixed Deadline Projects. Retrieved from.

http://www.pmi.org/learning/effective-management-fixed-deadline-projects-6937.

Kapur, G., K. (2004). Project Management for Information, Technology, Business and

Certification, Prentice Hall; 1 edition.

Passenheim, O. (2009). Project Management. 2009 Olaf Passenheim & Venture Publishing Aps.

Putnam, L, (1997). Industrial Strength Software. Institute of Electrical & Electronics Enginee;

First Edition (January 1997).