Plan and Planning - How we start a project
Last updated
Was this helpful?
Last updated
Was this helpful?
To start a project in KMS, we request the project lead to put together a wiki page for the project plan. The wiki page keeps stakeholders informed about the project's milestones, critical dates and the current state. It is also a good idea to link all the related documents about the project from this page. This wiki page is the go to page for stakeholders. The project plan is NOT set on the stone. It should be updated to reflect the latest understanding of the project's scope, requirements and milestones. We use dates to manage stakeholders' expectations. We use milestones as feedback signals to validate our estimate and assumptions. Many projects in KMS are somewhat ground breaking. There are always unknown unknowns. But we still need a plan, to give stakeholders estimates on the resource and time needed, otherwise we cannot start. We roughly divide our projects into two categories: 1. Deadline driven projects. These projects have hard deadlines that we need to meet for our customers or other teams. Missing the deadline will trigger a chain of negative impacts. For this type of projects, we work backward from the deadline and figure out our plan. A lot of time we have to reduce the scopes of the projects as we move along in order to meet the deadlines. We might deliver the Minimum Viable Product (MVP) first and follow up with incremental releases. 2. Internal function driven projects. We want to deliver certain functions in these projects within a time frame. There are importance and urgencies we agree about the functions, but there are no hard deadlines. For this type of projects, we use milestone dates as our yardsticks to manage stakeholders' expectations. For non-trivial projects, it might take multiple tries to get it right. So instead of trying to be perfect in our executions, we plan for failures. For examples, 1. Use feature flags so we can ship the changes incrementally to production, without impacting existing services. 2. Use Pre-Prod stages to validate our changes. 3. Use OneBox to turn on the feature with limited traffic, to control the blast radius. 4. Have a well practiced procedure for rolling back the changes. We will fail every so often, and that is OK, as long as we are learning. "Plans Are Worthless, But Planning Is Everything...But if you haven’t been planning you can’t start to work, intelligently at least." - Dwight D. Eisenhower