Delivering solutions from inception to implementation
IT projects can be complex to deliver. Depending on the project, they may involve many teams and phases, on shore and off shore, therefore it is essential to keep everyone aligned and focused on the main objectives of the project.
In this blog post, I will be sharing some guidance and practical tips in plain English on how I deliver a solution based on my years of experience from the field. The experience that I am sharing here mainly comes from the infrastructure and cloud services based projects which will differ from software development based projects. Nonetheless there are many similarities.
In my experience, the following five major phases fit nicely with almost all of the projects that I have delivered. These phases are common in many methodologies but are represented using different terminologies.
Some of the activities in the plan, build, and test phase will be iterative in nature where you will build or deploy a feature and after testing you may run into some bugs or issues which requires you to re-plan, fix, and re-test until that feature is ready for deployment.
Throughout this blog post, I have kept the guidance to a generic, high level and avoided referring to any specific product or solution in order to provide information as simply as possible. I hope this will give you some basic understanding and allow you to adapt it to your own specific project.
Towards the bottom of this blog post, I have provided a quick snapshot of the overall methodology for a quick reference.
In the following sections, I will expand on each of the phases and provide some practical tips and guidance.
You know what the customer needs but how do you make sure that both your customer and your team stay aligned and focused on how to meet those needs? You define a Vision. A vision sets the tone of the project. This is the most important phase of the project that provides the foundation to build your project upon.
You define your vision in terms of the goals you are trying to achieve. It brings your entire team together on a common set of criteria that translates the vision into reality. Start by creating a "Vision and Scope document" where you will need to clearly define and confirm the following important aspects of the solution with your customer:
- Vision Statement
- Scope and Objectives
- Use Cases
- Approach, Timeline and Deliverables
- Assembling teams and defining their roles, and responsibilities
In the following sections, I will describe those aspects in little more detail.
Creating a vision statement may seem trivial but I believe it is the most important aspect of the envision phase. It is like a tag line that reminds everyone what the project is about. It works like a guiding light to keep everyone on track. A vision statement should be short and precise. For example:
“Improve productivity and content management by providing users with a central storage and collaboration space for sharing content, information, and ideas.”
Scope and Objectives
Scope and objects are the specific requirements of the solution that you will be developing and delivering. You will need to clearly define the requirements that are in scope and the ones that are out of scope. Make sure that you review and confirm them with the customer to avoid any misunderstanding.
Tip: After reviewing the scope, send an email to your customer with what you have reviewed and discussed to confirm your understanding. It never hurts to over communicate.
Use cases define how the solution or the product is going to be used. Make sure to capture as many use cases as possible by interviewing the stake holders and end users. Depending on the solution, you will need to capture use cases from various different business functions and departments such as Human Resources, Operations, Sales and Marketing, Finance and organize them accordingly. You will also need to capture the level of permission required by each user group to use the product, such as read, write, and full control access. These use cases will also become the bases for the “user acceptance testing” (UAT) during the testing phase of the project.
Provide a demo of the product/solution to help your customer better understand and how they can fully benefit from using full breadth of features provided by that product or solution. This will also help with establishing use cases.
Approach and Timeline
Provide an estimated schedule for each of the phases and tasks within those phases. Add some contingency to the overall schedule. This will be the bases of your work breakdown structure (WBS) that you will be creating during the planning phase. Due to circumstances beyond your control, schedule can be impacted so make sure that your customer is aware of such risks that could impact the schedule. Clearly define what your team and your customer activities and responsibilities are going to be. Create a RACI chart to outline roles and responsibilities.
Provide a list of deliverables that you will be creating such as Design and Build Guide documentation. Also make sure to confirm what the acceptance criteria and process is going to be.
Assembling team and defining roles and responsibilities
Assemble a team and define their roles and responsibilities. Also identify and confirm customer’s SMEs, and stakeholders that your team will be working with. Create and confirm the reporting structure as to who is going to be directly reporting to whom. Create an org chart diagram to visualize the team structure. Depending on your project, you may also need to include an executive steering committee.
Pick a time when all or most of the team members are available to kickoff the planning phase. Start by jotting down the main aspects of the planning phase on the whiteboard or if you prefer on your laptop that is projecting on the screen. If your meeting is virtual than use the virtual whiteboard, Microsoft Word, OneNote or whichever application that you prefer to present notes.
The main outcome from the planning exercise should be the first draft of the Plan and Design deliverables and it should cover the following aspects:
- Communication Plan
- Work Breakdown Structure
- Functional Specifications
This will be a gradual process and can span several days.
The communication plan should consist of communication activities for both the project team and the end users.
The Communication plan for the project team should consist of communicating on activities such as collaboration, risk and issue management, document management, and status reporting.
The Communication plan for end users consists of communicating information on the delivery of the solution, impact, training, orientation, downtime, cutover or delivery date, and support.
Team Collaboration Site
If you have access to SharePoint or similar product, create a project team site for managing and collaborating on the project. This site will help with bringing all the status, communication, and artifacts relevant to the project into one place. On this project site, create list of contacts for all the team members.
Project Issues and Risk Management
Create lists for managing issues and risks, such as project creeps and change requests. You can easily create these lists by using the out of the box list templates available in SharePoint. Each issue and risk should be assigned an owner, status, priority, impact, description, category, and a due date.
Technical Issue Management
Create a separate list for managing technical issues such as bugs, installation and deployment errors.
As you are deploying the solution, it goes through many changes until you have the final product. Create a Change Log list to keep track of those changes.
Shared Document Library
Store and share the documentation that you will be creating from a shared document library.
Setup weekly status meetings with your project manager and customer. During the initial stages of the project, setup daily 15 minutes standup meeting. These standup meetings will be your opportunity to bond with the team and root out the factors that are common during the “forming” and “storming” phases of the project.
Tip: Setup weekly status meeting with your own project manager before your weekly status meeting with the customer. This will allow you to discuss any issues and be in-sync with your project manager before your meeting with the customer.
Provide weekly status report to your project manager and customer. Make sure to inform your project manager and customer of any risks and issues immediately, and document them in the status report.
Notify your project manager immediately if the scope of the project could potentially change. Any change to the project will impact both the schedule and cost. Make sure that your customer understands these impacts.
Identify if the customer has an existing governance model that they would like to use to support and operate the solution. Identify and confirm their standard policy and procedures and assist with establishing Service Level Agreement.
After you are done with planning the logistics of the project, next you will be working with the customer on the following specification of the solution. This a generic list which I am only providing as an example.
- Usage Scenarios
- User Requirements
- Business Requirements
- Operations Requirements
- System Requirements
- Conceptual Design
- Physical Design
Work Breakdown Structure
Work Breakdown Structure is your project plan for outlining each phase and tasks of your project. I like to use Microsoft Project application to create project plans but you can also simply use a spreadsheet. Break your project down into five distinct phases and provide detailed tasks for each phase and establish timeline and milestones. Again, the following is only a generic list which I am providing as an example:
The Build phase starts with the first iteration of the installation and configuration of a product or development of your solution. You go through multiple iterations until your product or solution is ready for deployment in the production environment.
In the test phase, you will test your product/solution for defects and configurations issues. You will need to do this for each feature that you are developing or a product feature that you deploying and configuring.
After initial rounds of testing and bug fixes, you will then put your product for pilot test, where the rubber meets the road, to get feedback from the actual end users. Identify the users who are willing to spend time and provide good concrete feedback that you can use to refine and optimize your product/solution. These users will test the product for normal use case scenarios. You will then take user feedback to further test the product and fix any addition issues and bugs.
After pilot, you will put your product for user acceptance testing (UAT) which is the last stage of your testing process before you are ready to deploy your product/solution into the production environment. You will again collect feedback from the end users to further optimize and refine your product/solution.
Deploy is the final phase of the project. In this phase, you deploy your product in the production environment, complete any remaining knowledge transfer and then hand over the product to the operations team. Your operation team will run and support the product based on the governance and service level agreement (SLA).
High level view of the methodology
Here is a quick snapshot of the entire process, including each phase, tasks, and activities.