¶ Project Management Policies & Procedures
Back to "Policies and Procedures".
¶ Project Management Lifecycle
¶ 1. Project Request Form
- The project request form serves as the starting point for projects, requiring an official, signed request to be submitted to CAS for approval. It should include a clear project rationale, anticipated benefits, and identification of pain points to be addressed.
Duration: 1-2 days
¶ 2. Project Scoping
- Project scoping is the process of defining the project's boundaries and determining what is included and excluded from the project. It involves clarifying the project's objectives, deliverables, constraints, assumptions, and high-level requirements. In addition the project team and stakeholders are also appointed as well as the project manager. In this phase, DTT usually performs the initial walkthru with the process owner. DTT's output for this scoping phase which contains the project's purpose, goals, deliverables, constraints, assumptions, high-level requirements and the scope of work is called the project charter. This is also the phase where the project can be decide if will be executed internally or will be outsourced.
Duration: 1-3 weeks depending on the availability of concerned parties.
¶ 3. Project Planning
- The planning stage involves a thorough examination of project details, including estimating timelines, budgets, resource allocation, risk management plan and communication plan. It also assesses the project's potential impact on the overall delivery timeline of DTT's project pipeline.
Duration: 1 week or more depending on the intensity and scale of the project.
¶ 4. Project Approval
- As part of the project approval process, CAS will sign an approval document, typically accompanied by the project charter and timeline, to officially authorize the project execution phase. Following approval, the project will be encoded to Coda while the Digital Transformation Team (DTT) begins development of the solution.
Duration: 1-2days
¶ 5. Project Kickoff
- The kickoff meeting introduces the project sponsor, team members, clarifies roles and responsibilities, defines project scope and out-of-scope elements, and covers key topics such as timeline, budget, communication protocols, and the schedule for regular meetings and updates.
Duration: 1day
¶ 6. Early Development
- Early Development marks the initiation of the actual project execution. During this phase, the project team focuses on setting up the necessary infrastructure, development environment, and laying the foundation for the solution. Key activities include initial coding, database design, and establishing the core framework. Budibase is used as a prototyping platform, allowing the developers to quickly create interactive prototype and gather valuable feedback at Sprint I Review.
Duration: 3weeks
¶ 7. Sprint Development
-
The sprint review is held every two weeks (or once a month depending on what the project team agreed on during the kick off) to assess progress and gather feedback. The sprint development is divided into three sprints (Sprint I, II and III). A sprint is then divided into two events, Review and Development.
¶ Sprint I
- During Sprint I Review, the project team together with the key users review the prototype from early development. Assessments and suggestions are then made into doable task which is then encoded to Coda for better monitoring and collaboration. After the Sprint I Review, Sprint I Development will start. This is the time when the developers will adjust or add codes to satisfy the comments and suggestions in Sprint I Review, it also encompasses the time when the developers will convert the Budibase Prototype into a web app using Vuexy.
- Sprint I Review Duration: 1day
- Sprint I Development Duration: 2weeks or more
¶ Sprint II
- In Sprint II Review, the project team together with the key users review the web app from Sprint I Development. The team will try to gather all the assessments and suggestions that are needed to finish the project. In short, the team will round up all the possible additional requirements for the web app to be ready for deployment. After the Sprint II Review, the development of all the discussed assessments will be worked on. This usually takes a longer time than the Sprint I Development. The developers will also improve the UI and UX of the web application including color themes, button names, section sizes, dashboards and tabs. This is also the part of development when the reports will be perfected with accuracy and precision comparable to the existing reports of the key users.
- Sprint II Review Duration: 1day
- Sprint II Development Duration: 2weeks or more
¶ Sprint III
- Sprint III Review will be done after the Sprint II Development, for the purpose of ending the development stage so the team can start the Testing and Validation stage. But, if for some reason the project can't proceed to Testing and Validation, like there's still features needed to complete, or the application needs some more polishing, then the team will do Sprint III Development to finalize the web application. Sprint IV Review will be done, to review the web application and officially end the development stage before proceeding to Testing and Validation stage.
- Sprint III Review Duration: 1day
- Sprint III Development Duration: 2weeks or more
¶ Daily Scrum
- Daily Scrum is done every day to assess and monitor the development during Sprints. This is usually done by the DTT Head, Project Manager and Developers.
- During Sprint I Review, the project team together with the key users review the prototype from early development. Assessments and suggestions are then made into doable task which is then encoded to Coda for better monitoring and collaboration. After the Sprint I Review, Sprint I Development will start. This is the time when the developers will adjust or add codes to satisfy the comments and suggestions in Sprint I Review, it also encompasses the time when the developers will convert the Budibase Prototype into a web app using Vuexy.
-
Attached is a typical Sprint Review Presentation Template.
Any enhancements or requests beyond the initial scope require a signed change request form, which follows the same approval process as the project charter.
¶ 8. Testing and Validation
- In this crucial stage, both the Development and Testing Teams (DTT) and end-users conduct meticulous internal testing to validate the functionality and accuracy of features within the application. The project manager assumes the responsibility of creating a comprehensive form designed to scrutinize the web application's core features, extending from dashboards to reports. This form serves as a standardized checklist to ensure thorough examination.
¶ Initial User Acceptance Testing (UAT)
-
During this phase, an Initial User Acceptance Testing (UAT) is conducted to gather valuable insights and inputs essential for the refinement of the application. A selective group of 3 to 5 users is carefully chosen from the department to actively participate in the UAT process. These users are provided with UAT Forms, meticulously outlining the core features and specific functionalities that require scrutiny.
-
The UAT Forms incorporate a dedicated section for remarks, allowing users to provide additional comments and suggestions. However, it is imperative to note that comments and suggestions do not automatically become part of the web application's scope. Each comment or suggestion undergoes a thorough assessment and discussion to ascertain their validity and relevance. Those deemed reasonable are considered for inclusion, while those falling under the categories of "Nice to Have" or "Not worth developer's time" are carefully evaluated and documented accordingly. This meticulous process ensures that the web application is refined with a focus on essential functionalities and user requirements.
-
¶ 9. UAT - User Acceptance Test
¶ 10. Training
¶ 11. Certificate of Completion and Acceptance (COCA)
- The COCA document allows the project sponsor and CAS to review and approve the fulfillment of all project requirements by the project team and that the system or solution is properly turned over. Once signed, it marks the official closure of the project. Any additional requirements will be addressed in a succeeding project phase, initiated with a separate project request form.
- The COCA lists the persons involved in the quality testing and validation, the person whom the system will be turned over, the persons who will be the system admin/s, and the person who will be in charge of managing and operating the system.
Duration: 1-2days
¶ 12. Go Live and Operation
¶ Project Initiation and Planning Protocols
The project initiation phase entails presenting a comprehensive overview of the project, encompassing its purpose, objectives, and alignment with organizational goals. This phase involves identifying stakeholders and delineating their roles and responsibilities within the project framework. It also encompasses defining the project scope, outlining both the inclusions and exclusions, while specifying any constraints and assumptions that might impact the project's direction and execution. This process serves as the cornerstone, establishing a clear understanding of the project's aims, involved parties, boundaries, and contextual limitations, guiding the project's successful trajectory.
It also involves conducting a kickoff meeting designed to introduce the project, elucidate its objectives, and familiarize team members with their roles and the overarching goals of the initiative, ensuring a unified understanding and a strong, collaborative start to the project.
DTT follows below structure with regards to Project Kick Off Meeting:
-
Opening Remarks:
- Welcome and introduction to the meeting's purpose and agenda.
-
Project Background:
- Overview of the project's origin, context, and any relevant historical or background information.
-
Project Objectives:
- Clear articulation of the project's aims, goals, and expected outcomes.
-
Project Teams and Roles:
- Introductions and clarification of team members' roles and responsibilities.
- Mors note: assign project deployment head (outside DTT) for training etc; assign coordination/relations head in charge as the point of contact of developers to the process owners; project sponsor from mancomm or higher they need to be updated as they will be the ones to update during coda and to encourage a more hands on approach
-
Project Scope and Features:
- Definition of the project's boundaries, what's included and excluded, and a breakdown of key features.
-
Project Timeline and Milestones:
- Presentation of the project schedule, major milestones, and important deadlines.
-
Feedback Gathering:
- Encouragement for questions, suggestions, or concerns from team members.
-
Service Level Agreement:
- Discussion of service-level expectations, commitments, and deliverables.
-
Maintenance and Support:
- Outline of ongoing maintenance and support procedures post-project completion.
¶ Project Categorization 🚧
- what is the difference in procedures in each category
¶ Waterfall - Agile Hybrid Project Management
The projects are planned upfront, and each set has its own set of deliverables and milestones (Waterfall Method) but there are projects where requirements can evolve and are accommodated during the development process (Agile Method).
Digital Transformation Team adopts a hybrid approach, combining elements of both methodologies to create a method that best suits the specific project needs which often depends on the project's nature and client requirements.
Large projects are broken down into smaller iterations or sprints, where features are developed and delivered incrementally in short cycles. Sprint Reviews are done every 2 weeks to ensure that the developer team and the user department is aligned with the features and deliverable expectations of the project.
¶ Task Assignment and Monitoring
The team utilizes Coda.io, the project management tool that allows them to leverage a versatile platform that combines document creation and database functionalities in a collaborative workspace. It supports task tracking, team collaboration, and project planning through customizable templates, Gantt charts, task lists, and kanban boards. Its flexibility and adaptability permit the team to design workflows tailored to their specific project needs, facilitating seamless communication, task management, and overall project coordination within a single platform.
- DTT Project Monitoring in Coda
- DTT Tasks Monitoring in Coda
The bi-weekly meeting (Mancom - CODA Meeting) serves as a regular forum for collaboration and alignment between the Digital Transformation Team (DTT) and various Department Heads. This recurring gathering facilitates open communication, exchange of updates, and the sharing of progress, challenges, and strategies between the DTT and Department Heads. The meeting aims to foster cohesion, encourage cross-departmental collaboration, and ensure that everyone is informed and on the same page regarding the progress and direction of digital transformation efforts.
- Mancom - CODA Meeting, by Priorities
¶ Project Timeline
Creating a project timeline and monitoring it in Coda.io involves using the platform's features to outline and track the various stages and tasks of the project.
A. Creating a Timeline
DTT utilize Gantt charts within Coda to create a visual representation of the project timeline.
B. Task Breakdown:
Break down the project into smaller tasks or milestones and input them into the timeline, specifying their start and end dates.
Dependencies and Relationships:
Use Coda's functionality to link tasks that are dependent on each other. This could involve creating formulas or conditional formatting to show task relationships.
Customization and Formatting:
Customize the timeline with colors, tags, or other visual cues to signify task status, priority, or different phases of the project.