Please login or join to subscribe to this thread
Quickly might be a challenge. Identify the actors, scenarios, inputs and outputs, data and process flows. Details hide in data and process.
Can you build something iteratively, or does it have to be big bang? If you can build in iterations, start with actors and scenarios, then prioritize which to tackle, first. You'll likely have some rework, but you'd probably have rework if you went big bang.
As Aaaron noted, quickly implies that there is a limited time to plan and then execute.
Do it iteratively (aka Kanban or Scrum style). You'd still accumulate some technical debt and would have to refactor, but it would be less expensive than long planning and then big bang.
What about the churn of iterations is still too much and "I don't have time to talk, just do it" - an organizational rigor mortis settles in?
I call this technique Strategic Rapid Planning:
(1) A simulations understanding of long-term objectives and their prioritization (strategic)
(2) Simultaneous breaking down long-term objectives into activities/phases/WIPs (operational) to procesize what can be procesized
(3) Simultaneous managing piece work for each person, while instant re-shifting priorities, and executing a daily create-test cycle (tactical)
I found this type of PMing is prevalent in startups with small collocated teams that really want to work together. It works for them.
It is not suitable, however, for mature firms because complexity of hierarchies and dependencies on other systems will fry PM's brain if done over long period of time.
I would suggest the following when you need to resolve the details of a new database expeditiously (at and ERP level).
- Create a mini-workshop to resolve the “Logical ERD – Entity Relationship Diagram.” You will need an architect, DBA, or systems analyst (a.k.a. the Modeler) who is familiar with notating and visualizing ERD’s and who feels comfortable interrogating an audience to get the necessary information. In this workshop, you will have the PM, the Modeler, functional/technical SME’s, and some of their support personnel. The PM should be in charge of and guide the meeting, but the Modeler is the key player and will be doing most of the work.
- The Modeler will be visualizing the ERD on a whiteboard (physical or digital) and purposely challenging the audience to get the necessary information. At the end of the meeting, you should have a visualized logical representation of the high-level entities needed in the database. This will include the relationships the entities have with each other (i.e., cardinality and ordinality), along with known attribution for each entity.
- After the logical ERD is created, the Modeler will work with the technical team to realize a “Physical ERD.” The physical version will be the actual entities that will need to be created in the database. As part of this process, the technical team is also working with the SME’s further detailing the required attribution (NOTE: detailing attribution is an iterative process) and adapting the model when necessary as further information is discovered.
There are many other considerations to make, which an informed modeler will resolve, such as the degree of physical change that is expected in the database (i.e. how often do the entities need to be extended to carry additional knowledge), which then affects the normalization-form that is chosen, etc.
Using visualization techniques with the business, especially the logical ERD forms, provides a jump start to the physical realization of a database. However, what makes this process truly expeditious is having a “Modeler” who can dynamically adjust in a workshop format, evolving a model in real-time. If you do not have one on staff, then you may need to bring one in as a consultant for the necessary period-of-time.
Databases can be quick, but organizational SSOT ones are never quick.
Thanks, all! These are helpful - I'm proposing an iterative approach if speed is the driver - still need to confirm what is driving the project.
As Sante mentions a DB can be quick, very quick BUT the biggest problem with quick is this - We often find that it does not support our operational objectives. I have one golden rule that I always leave with my customers and it is this:
When you start planning something work backwards. So, identify and list your objectives, then list what you need to meet these objectives (function, process etc.) and then list how you plan to track efficiency.
That way you achieve a few things. You know what data you need, you know what data types you need and you also know what would be the best way to capture it. If for example, you will be using a certain metric on a dashboard to track your objective then you will be dead if you use the wrong data type or data entry mechanism that is potential not supported by the BI platform or graph type you want to use.
Please login or join to reply