Project Management – AWS Data Warehouse – II




Project Management – AWS Data Warehouse – II

The following post is a list of considerations when developing an AWS Data Warehouse solution.  Use it as a good starting point for discussions with architects, project management and stake-holders. There are many times when starting a new data warehouse project and you’re not quite sure what should be a priority. Use this list as a set of guidelines. Every DW project will have Project Management (at some level), Data Sets (source – destination), Resources (Developers, TPM’s, hardware, software) and More…

Now, Add the wrinkle of building the DW in the Cloud on AWS with Redshift, RDS, EMR, Hadoop, Data Migration and other services. It can be quite overwhelming and complex. Over the next few post, I will expand the list and deep-dive a few of the items and hopefully, give you and your project team some great answers.

If your starting an AWS Data Warehouse project and/or have questions; Please Email Us, We’ll get back to you ASAP.

Part II, Project Management –  AWS Data Warehouse solution.

Project Management 

  • Road Map – Features – Scrum (Story Board Items)
  • Project Time Line
  • Expectations of Stakeholders
  • Completion Criteria
  • DevOps – Long Term Support

Road Map – Features – Scrum (SBI)

Now that you have created your backlog items, how do you navigate it? Creating a route which road maps these backlog items is essential for any project, no matter the scale. Roadmaps organize stories into an effective model that enables you to understand system functionality, identify any gaps and impediments in the backlog and effectively plan a full product release. This, in return, delivers value to your users and your business.

So where do we start? By organizing stories in a grid like manner, we can categorize them by application, theme, and functionality. The Grid is an ideal bench-marker to build upon. Once Featured User Stories are established, you can begin slicing, or prioritizing stories in accordance to iteration with higher priorities on the left to lower ones towards the right. Because this is a dynamic model; user stories can be changed and moved around depending upon project requirements and/or needs.

From here, you can begin to break down your road map in more detail by color coding. These colors can symbolize anything from identifying complexity, business (non-functional) vs technical requirements, features to be completed in a later iteration, and so on. Its adaptive to your project and can be modified to your project needs.

Road Map

Project Timeline

Features are imperative in a project timeline. While a roadmap helps navigate the features, the timeline is based upon the iterative feature priority and how much functionality the team can deliver within a given timeframe. This is done in six steps:

  • Gather all requirements.
  • Perform analysis work on all of the required functionality
  • Perform design work on all of the required functionality
  • Develop code for all of the required functionality
  • Test all of the required functionality
  • Deploy all of the required functionality

These are completed through a series of iterations, changing the project requirements as needed. At a high level, iterations can vary between 2-4 weeks in which features transforms into deliverables. These prioritized functionalities and velocities create detailed roadmaps comprising user stories delivering functionality. This multilayered planning permits adjustments to changes in priorities, changes in the team, better approaches, and techniques learned during previous iterations.

Expectation of Stakeholders

Like the Agile SDLC, stakeholders request may change as frequently as the project features itself. Each new request has a price and timeline, which impacts the project deliverables in unique ways. Agile’s versatile approach provides stakeholders a much better idea of the project state because they can see and use the end result as it becomes available in shorter iterations. If a stakeholder chooses to change requirements, that is fully within their right. Agile’s approach allows for these changes and can deliver in shorter time span given complete transparency across the board.

Completion Criteria

The development team defines the definition of done in contingence with “This story is done”. Considerations of done can be found within these questions:

  • Is the code complete – as defined by the organization or teams.
  • Has the code undergone a unit test – as defined by the organization or teams.
  • Has there been a peer review – as defined by the organization or teams.
  • Is the QA Complete – as defined by the organization or teams.
  • Is there ample documentation as specified by agile specifications – determined by the Scrum Team.

Next, the acceptance criterion is tested.

  • The Product Owner produces a list of expectations for specific Product Backlog Items at the beginning of a Sprint.
  • The Product Owner and ScrumMaster or Development Team defines Product Backlog Items.
  • Minor changes can be implemented towards the Acceptance Criteria by the Development Team, ScumMaster, and Product Owner.
  • A Product Demo is commenced to overview once the Development Team believes it has met the Acceptance Criteria during the Sprint in which the Product Owner determines the Acceptance Criteria has been met. This deems the User Story done.

DevOps – Long Term Support

Once the project has been “delivered”, it is offloaded to a DevOps team to maintain for long-term support. It is not longer a project, but an operation integrated into the company for return on investment. This can be achieved through tidying up any lose ends by ensuring all code is deployable, environments decommissioned, paperwork filed (or shredded) and boards tidied up.

A review of the project is next on the agenda. Retrospectives are imperative to ensure the answer to the following questions:

  • What did we learn?
  • What could we have done better?
  • Did we finish the project on time?
  • Did we finish on budget?

This gives ample closure to disbanding the project while allowing take-aways for the next project. The project and team is completed and now it’s time to look forward to the next. So what’s next? It’s time to go back to the drawing board and map out a new project!

If you have questions about your IOT, EDW, AWS or Analytics project, Please Email Us – We’ll will respond ASAP.

Please Contact US or Subscribe to our Blog if you found this interesting or would like more information.

Subscribe : Blueskymetrics Blog

* indicates required,  Managed By Mail-chimp – Please check your Spam Folder and Confirm Subscription.