Project Management Process: The Distributed Decision System

Introduction

A project plan may be defined as a formal, official document created in order to set clear, understandable guidelines for and to provide direction to both project operation as well as project control. The main reasons for creating such a document are to help efficient and productive planning assumptions, aiding the decision making process with respect to various aspects of the projects, to facilitate effective communication and interaction amongst stakeholders, and clearly define variables related to scope, budget, and schedules. The document may be a summed up description of the project variables or a detailed explanation of the processes involved. Experts in the field refer to the project plan document as an account of the way in which a project’s goals in terms of operation and schedule are to be realized, by outlining the key deliverables, milestones, processes and assets needed for the proper execution of the project.

Project Overview

The current project under consideration is named The Distributed Decision System which essentially is a expert system meant for the use of large corporations wherein the decision makers are geographically scattered and face difficulties to coordinate the decision making process.

The aim of the project is to develop a distributed application system that aids key business decisions to be made without the help of any conference calling procedures or even implementing any other form of media for conversation. The software lets top level managers of a corporation to create a relevant business scenario, to inform the members of the decision making team scattered across any part of the globe and to gather their perspective through a polling response process, by means of SMS or email. Additionally, the architecture of the software incorporates other mediums of digital communication such as voice mails or streaming video formats to collect polling responses. (Labuschagne, 2005)

Outcome and Deliverables

The result of the execution of the entire project should be an effective functional trial product incorporating all the essential and desired components and functionalities in addition to items such as a detailed project plan, system architecture, blueprint and test cases manuscripts together with derivatives and products like installation and usage guides and manuals.

The following list describes the intended deliverables of the project as a part of the entire software package:

1. Operational and Schedule Plan and Process Description manuscript
2. System Requirement Specification document
3. Software Architectural Description and Application Design explanatory documents

   1. High Level Design document
   2. Low Level Design document

      1. Algorithm
      2. Error handling and Troubleshooting guide
      3. Data Routing and Transformation information script
4. Document explaining technicalities of relevant Mobile Communication used in the project
5. Implementation Process Document

   1. Coding and Scripting manuscripts
   2. List of External Softwares interacted with by the Distributed Decision Application
6. Verification and Validation

   1. Test Plan Document
   2. Test Case Document
7. Installation and Usage Guide (Hodgson, 2008)

Work to be Performed

A thorough understanding of the specific requirements of the customer is essential. Thus the consecutive phases of feasibility evaluation, planning, design and implementation guidelines are to be decided initially at a very early stage of the project. These guidelines are to be aligned with the outcome of the requirement engineering process. The iterative waterfall model is to be employed for project planning process and Scrum approach will be adopted due to the small size of the project team, limited time, effective dependency on informal communication techniques and ambiguity in requirements during the early phases. (Bowers, 2006)

The project meticulously focuses on the architecture, design and planning, algorithms and user interfaces, which constitute the set of most critical evaluation elements. Bearing such issues in mind, a rich architectural design that provides for a scalable, loosely coupled and modular system, free of complex technicalities, has to be crafted.

Thus the project needs to be developed as an integrated software system combining various software applications. The SMS Gateway, the web application and mail server constitute the modules which work in concert to lend the system its multi-functional character. All the modular applications in the project are to be linked by means of a middleware component taking care of the issue of loose coupling. (Johnson, 2006)

Roles of Team Members

The entire project team will be led by a single project leader and the team would be divided into a hierarchic structure. The project leader would be responsible for the entire project, would interact with the client and supervise the operations of every group involved in the project. The communication framework, deliverables, policies, tactical operations, risk management are the functionalities that is to be taken care of by the project leader.

The team would be split into various sub teams each with its own dedicated functionalities. These teams are to be led by specific team leaders who have to ensure that the operations of their teams are progressing smoothly and are synchronized with the operations of the other teams. The sub teams to be formed are the front-end team, middleware team, and the back-end team.

Each sub team would then be divided into design, development, testing and implementation groups. Additional special teams may be formed by picking out resources from these primary teams as the project progresses. Objectives, timelines and milestones should be clearly communicated to each member of the entire project team and their work should be aligned with such factors. (Vanharanta, 2009)

Project Schedule

The schedule has been divided into stages wherein there will be a primary and secondary focus on specific activities. However, there may be some activities which may not be mentioned here but can be carried out at a particular stage if the need arises. A specific time-duration has been allocated to each execution stage of the project which is to be strictly followed.

Stage 1

• Primary Focus: Project evaluation, Planning
• Secondary Focus: None
• Duration: 1.5 weeks

Stage 2

• Primary Focus: Requirement Engineering, Analysis, Project Definition
• Secondary Focus: Planning, Architecture design
• Duration: 3 weeks

Stage 3

• Primary Focus: Architecture design
• Secondary Focus: Requirement Engineering, Analysis
• Duration: 2 weeks

Stage 4

• Primary Focus: Architecture design, Technical preparation
• Secondary Focus: Analysis, Communication Layer development, Business Layer development
• Duration: 3.5 weeks

Stage 5

• Primary Focus: Analysis, Communication Layer development
• Secondary Focus: Business Layer development, Technical preparation, Front-end and back-end implementation
• Duration: 2.5 weeks

Stage 6

• Primary Focus: Communication Layer development, Business Layer development, Unit Testing
• Secondary Focus: Front-end and back-end implementation, Functional Testing
• Duration: 7 weeks

Stage 7

• Primary Focus: Business Layer development, Front-end and back-end implementation, Unit Testing, Integration Testing, Functional Testing
• Secondary Focus: Communication Layer development, System Testing, Alpha Testing
• Duration: 5 weeks

Stage 8

• Primary Focus: Unit Testing, Integration Testing, Functional Testing, System Testing, Alpha Testing
• Secondary Focus: Communication Layer development, Business Layer development, Front-end and back-end implementation,
• Duration: 5 weeks

Stage 9

• Primary Focus: Project Report development
• Secondary Focus: Testing, Correction of development anomalies
• Duration: 2.5 weeks (Hodgson, 2008)

Budgetary Consideration

The scope and magnitude of the project requires that there is an effective deployment of assets and resources in order to fulfill the needs of the project and meet the described timeline. The entire project team needs the expertise of 60 skilled personnel. Hardware and Software requirements are as follows:

• 60 networked systems
• 5 dedicated servers
• Java APIs
• JBOSS middleware architecture
• Microsoft Project Planner
• Report Generators
• Oracle 10G
• The total cost for the execution of operations has been estimated at $45000.

Assumptions

The following assumptions have been made which have to be true throughout the course of the project in order to deliver the completed deliverable system on time.

1. Client Requirements are clearly understood and defined.
2. No hardware anomalies are non-existent.
3. No software anomalies are non-existent.
4. Technology interoperability issues do not exist.
5. All required resources are allocated to specific domains in time.
6. No delays occur in the course of operations of each stage.
7. No changes are made to the scope of the project. (Johnson, 2006).

Project Risks

The following risks have been associated with the execution course of this project. Each risk has been categorized in accordance with the level of impact it has on the overall progress of the project. In addition, a risk prevention or mitigation strategy has also been drafted.

1. Time shortage: This has been classified as a high impact risk. In order to avoid this particular risk the timeline and activities for each execution stage has been carefully defined and has to be clearly communicated to all the team members. A proper planning and managing framework (Scrum) has been adopted so as to ensure that the course of execution is planned well in advance and monitored throughout the implementation phase.
2. SMTP email server, IP port and Identification records: This risk has also been categorized under the high impact category. In order to avoid this risk a properly configured version of Microsoft WINMAIL Server is required.
3. Software communication with mobile devices: Categorized under the high impact risk category. Java service API has to be made use of properly to communicate with mobile devices through COM 7 port in order to deal with this particular risk.
4. Technical Competence / Skilled Resources: Categorized under the medium impact Category. In order to mitigate this risk element personnel should be provided with adequate training and knowledge transfer mechanisms must be used.
5. Limited Customer Interaction: Categorized under the medium impact category. In order to mitigate this risk factor a team member was assigned the role of the customer liaison. (Koskinen, 2009)
6. Miscommunication: Categorized under the low impact category. So as to deal with such a risk all major communiqués are to be manually as well as digitally documented. Team members in managerial positions are to make sure that all communications are clear and transparent.
7. Server Malfunctioning: Categorized under the low impact category. In order to mitigate this risk factor regular updates must be backed up in an effective manner.

Commentry

Interaction with the Stakeholders

A stakeholder is any person or association whose interests are influenced by a certain project initiative or who / which considers that the project outcome may have an effect on its wellbeing. Interests may be economic or non-economic, optimistic or pessimistic, and can be influenced during the course of development of the project or upon conclusion of project operations.

The stakeholders in this project are the customer and our company. Thus the project plan was addressed to the client and a copy of the project plan was also forwarded to the top level management of our company. In order to maintain transparency as well as to foster a better understanding amongst the project team members and the various stakeholders in the project an effective communication framework was needed.

However, interaction up to a certain limit is considered to be constructive. In case the boundaries are violated there is a negative influence on the project outcome. Thus an optimum level of interaction was necessary for the effective fulfillment of the project objectives. Thus, it was decided that project stakeholders were to meet and review once after the completion of each stage of the project operation in order to monitor the overall progress of the project. These meetings also served the purpose of better understanding the stakeholders and gather update and clear doubts which were hindering the smooth execution of operations. (Johnson, 2006)

Success Criteria

Describing explicit success criteria in the course of the initial phases of a project helps the stakeholders to maintain their focus on the collective intents and ascertains specific targets for the appraisal of the progress of the project. A four-fold process was adopted in order to determine the success criteria for this particular project.

The process of establishing effective success criteria involved the following:

• Identifying, recognizing and understanding the project stakeholders and their needs;
• Describing clear business targets and objectives for both the project handling organization and the client;
• Recognizing and determining the constraints that narrows the management’s choices;
• Aligning the success criteria with the business objectives of the client as well as the development company.

A project is considered to be successful if it delivers and adds some value to assorted stakeholders–individuals, groupings, or associations that are directly implicated in the project, are impacted by its result, or can have an effect on its outcome. Thus the quest for the success criteria was initiated by determining the specific stakeholders and their needs and demands.

Clearly defined business goals and objectives serve as a measure to evaluate the overall feasibility of undertaking a project. Every business target can subsequently be translated into explicit, achievable, confirmable, and prioritized objectives that were used to evaluate the results and confirm the fulfillment of such objectives. (Koskinen, 2009)

Constraints portray the limitations and precincts within which the management of the project must execute their operations. Thus, while determining the success criteria of the project it was important that these constraints were recognized and determined.

Each business goal or target entails certain specific technical success criteria that can be scrutinized and observed before the release of the deliverables of the project. The developers of a project cannot right away fulfill the business objectives of the various stakeholders involved. However they should be competent enough to translate such objectives into explicitly planned project activities that facilitate the realization of those aims and objectives. Thus the success criteria needed to be aligned with the strategic goals and targets of the implicated stakeholders. (Dalcher, 2009)

Project Plan Structure

Minimally, a project plan document must be capable of providing satisfactory answers to fundamental questions like why, what who when in the context of the project. It must be able to enlighten the reader about the problem or value proposition tackled by the intended deliverables of the project and state the basic reasons underlying its instantiation. It should be able to provide information about the work that is to be carried out during the development project and describe the key outcomes and deliverables. In addition, it should provide information about the resources implicated and the responsibilities and functionalities of the personnel involved in the project. The structure and formation of teams should also be described in such a document.

Finally, information about timelines, milestones and delivery dates should be explicitly mentioned in a project plan document. Additionally, the document may also include information about the assumptions made for the smooth progress of the project, budgetary considerations and risk evaluation. (Vaagaasar, 2009)

Bearing in mind such requirements this project plan adopts a comprehensive approach describing all the necessary elements that are required to explain the project entirely and is structured in a manner that would facilitate a smooth and quick execution of the project activities. The project plan includes the following:

• Introduction
• Project Overview
• Outcome and Deliverables
• Work to be Performed
• Roles of Team Members
• Project Schedule
• Budgetary Consideration
• Assumptions and
• Project Risks

Assumptions, Constraints and Challenges

There were a number of assumptions made during the planning phase of the project. Those conditions needed to be true throughout all the phases of the project in order to develop the project smoothly and flawlessly. The assumptions included condition like hardware and software anomalies being non-existent, requirements being clearly communicated and understood, non-existence of technical interoperability issues etc. However, like any project this project was also exposed to certain challenges. The project team was constituted by 60 team members of various nationalities. Some of them did not have English as their mother tongue. Thus in some cases communication emerged as a significant problem. The unavailability of the customer at times posed a major challenge and proved to be a hindrance to the progress of the project. The stringent time constraint was a major challenge for this project. The total estimated time for the completion of this project was 32 weeks. However, this was based on the criteria that the assumptions made in the project plan were true. Another significant challenge was assigning the roles and responsibilities to 60 different team members. Each member differed in proficiency level and domain skills. To maximize the productivity of the operations each of them had to be assigned different roles keeping such factors in mind. However, we are thankful to our organization that there were no difficulties on the resources and budgetary fronts. All resources were supplied when necessary and in time and the liquidity of the assets were of a more than satisfactory level. (Lee, 2007)

Project Management Process

The Distributed Decision System development process involved a range of activities. These activities were required to be allocated and controlled in a manner that maximized the productivity of team members and the overall operation execution. Being a distributed team, interaction amongst various teams emerged as one of the key areas of consideration from the management viewpoint. Various schemes were employed in order to ensure that an effective communication framework exist through which team members could interact. Periodic formal meetings were organized by making use of video conferencing technology in order to talk about progress status of responsibilities allocated to various personnel. Scrum meetings and kick off meetings were regularly organized in the course of the implementation process. The discussions in each meeting were carefully documented with a clear account of the meeting procedures and responsibilities allocated to specific individuals to be carried out prior to the subsequent meeting. Two project status presentations were organized during week 12 and week 27 to discuss and review overall project progress. Specific roles were defined for the various different activities. Each team member was made accountable for a particular task in line with the responsibility assigned to him /her. A structured approach for hierarchical communication was drafted. All team members were given the freedom to interact with the project manager directly. However, only the project manager was responsible for interactions with the client and the senior management. Every problem and uncertainty of a team member which needed to be communicated to the client or the top level management had to be channeled through the project manager. (Vaagaasar, 2009)

Management Tools

The Iterative Waterfall Model and The Scrum approach were used as management tools for the project. The waterfall model, used in the planning phase of the project, is a sequential software development model, wherein the progress of the project operations is considered to be flowing progressively downwards going through the stages of Conception, Commencement, Analysis, Design (validation), Construction, Testing and Maintenance. The Scrum approach is an iterative incremental structure which helps in the management of complex initiatives like the development of a new product. The project also makes use of the agile software development methodology which is compatible with the Scrum approach. (Ren, 2008)

Conclusion

Thus, it ca be stated that this project plan document is capable of providing satisfactory answers to fundamental questions like why, what who when in the context of the project. Bearing in mind such requirements this project plan adopts a comprehensive approach describing all the necessary elements that are required to explain the project entirely and is structured in a manner that would facilitate a smooth and quick execution of the project activities. There were a number of assumptions made during the planning phase of the project. Those conditions needed to be true throughout all the phases of the project in order to develop the project smoothly and flawlessly. The project team was constituted by 60 team members of various nationalities. The stringent time constraint was a major challenge for this project. All team members were given the freedom to interact with the project manager directly. Thus, there is every chance of success for the project.

References

Bowers, J. (2006). System dynamics in project management: A comparative analysis with traditional methods. System Dynamics Review, 12(2), 121-139.

Dalcher, D. (2009). Project reviews, assurance and governance. Project Management Journal, 40(2), 107-116.

Hodgson, D. (2008). Disciplining the Professional: The Case of Project Management. Journal of Management Studies, 39(6), 803-821.

Johnson, K. (2006). Organizational structures and the development project planning sequence. Public Administration and Development, 4(2), 111-131.

Koskinen, K.U. (2009). Project-based company’s vital condition: structural coupling. An autopoietic view. Knowledge and Process Management, 16(1), 13-22.

Labuschagne, C. (2005). Environmental and social impact considerations for sustainable project life cycle management in the process industry. Corporate Social Responsibility and Environmental Management, 12(1), 38-54.

Lee, Z.W. (2007). Effects of resource allocation policies for reducing project durations: a systems modelling approach. Systems Research and Behavioral Science, 24(6), 551-566.

Ren, Y. (2008). Risk management capability maturity model for complex product systems (CoPS) projects. Systems Engineering, 6(21), 116-124.

Vaagaasar, A.L. (2009).Project management improvement efforts – creating project management value by uniqueness or mainstream thinking? Project Management Journal, 40(1), 19-27.

Vanharanta, H. (2009). Project management: The task of holistic systems thinking. Human Factors and Ergonomics in Manufacturing, 10(2), 223-234.