Key Takeaways
1. Great discoveries make great projects. Without them, you are flying blind (in most cases).
2. Validating a project’s statement of work (SOW) in a discovery is step #1–must catch misaligned assumptions, undefined requirements, and project risk.
3. Typical outputs of a well-done discovery include current and future state diagrams of product data flow, owners for each stage of that flow detailing what they are accountable for, and goals with associated KPIs for the planned changes.
“Why do I need a discovery?”
As a lead developer, I cringe a little every time I hear this question on a new implementation. Not a terrible question, since cutting down on inefficiencies is key to successful projects and profitable work. And I love prioritizing features and creating tight, minimum viable products with planned phases.
So why do I hate being asked that question on discoveries?
“An ounce of preparation is worth a pound of cure” – Ben Franklin
Short answer… a successful discovery is essential to a successful project. Discoveries ensure that project assumptions and expectations are accurate and aligned. Any cost savings achieved by cutting corners in a discovery greatly increases the risk that the project will go over budget, fail to achieve the most important goals, and, in the worst cases, completely tank.
Given the importance of this phase, what are the key deliverables for every discovery?
Validate the Statement of Work (SOW)
Gathering requirements and defining success for a project really begins during the initial sales call. Those initial notes lead to a SOW, where we as consultants start being paid for our work. Technically, hours spent in the sales pipeline are not billable, as they occur before the project begins. Sure, evaluating data sources, destinations, and catalog complexity happen early on but until the SOW is signed, it is not a paid engagement.
My initial responsibility as a developer, therefore, is to validate that the SOW is representative of the work required.
To validate the SOW, I typically need to review data samples, their formats, and map the flow of that data as it operates today. Work cannot begin without an accurate representation of data flows that have been validated by a customer stakeholder who can grant access, troubleshoot, and answer questions.
Validate the Solution
Multiple times on PIM projects, I have started work based on a client’s word that a data export contained all the relevant product data, only to waste weeks of development on an incomplete data set. I have seen projects start with an expectation of using one eCommerce platform for integration, only to change months later because the platform could not manage a data model’s complexity.
The ideal time to discover these shortcomings in product data or limitations of an eCommerce integration is during the discovery phase. At that point, no rework is required, and everyone still has time and resources to adjust to new challenges. Taking the time to plan out at a high level of detail any complex mappings and integrations now will pay dividends later. Also, I cannot stress the importance of obtaining complete data exports as early as possible to avoid any surprises once the work begins.
Enlist the right people
Getting the right people in the room does not guarantee a successful discovery but missing critical people will cripple your PIM project’s chance of success. Who are these people? Unfortunately, it really depends on your business structure. But a few key groups include:
- Information Technology (IT) & Related
- ▪ Specifically, any integrations teams for eCommerce, catalog, ERP, or other internal team. Their time is valuable, so I prefer them for a half day or less. Specifically, the reduced face time will help ensure the PIM project is driven by product content owners rather than IT.
- Current Product Managers
- ▪ Who are your “Julias?” In Akeneo’s language, a “Julia” is the person directly responsible for a product’s or range of products’ content on the web. Most of the time, the Product Manager or Owner (as in agile frameworks) is representative, but anyone who generates product content downstream should be considered.
- Management Team
- ▪ They will likely be needed only for a high-level overview and strategy meeting. Leadership should hold teams accountable for employing the PIM using best practices while ensuring data quality is improved and maintained moving forward.
Typical outputs of a discovery
How do you know you have accomplished your goals? The following outputs are a sign of a well-executed discovery:
1. Current Product Enrichment and Data Flow
A good system diagram with people, data formats, and timing is essential, even if you plan on reworking the entire system. When work begins, it is critical to be able to contact the right person to get clarification.
2. Proposed Product Enrichment and Data Flow
This must include data and mechanisms for the complete system in addition to users and roles. For example, include in the diagram details like the following, “ERP (AS400) CSV export sent dropped in the ‘/data/transfer/pim’ daily at 6PM EST. Imported to the PIM at 7PM EST via cron job command.”
3. Also include…
Attribute Owners: Specify what data will be managed, where, and by whom? This will probably change in time, but a rough idea of what product attributes will be enriched and where is very helpful for development purposes.
Future System Goals: It is not always possible to plan for the future, but if there are plans for a new Digital Asset Management (DAM) system, new eCommerce system, or expansion into new markets in the coming years, you can save yourself a great deal of headaches by jotting them down on the data flow map.
Data Samples: Full data exports to load into your PIM. If a full data export is not possible, it is important to understand how to chunk that export into manageable pieces.
Limitations of a discovery
It is important to recognize that a good discovery will not solve all your future problems. New problems will arise, priorities will need to adjust, and the project may have a new scope. The real value of a discovery is to have the hard conversations first in a project and find the initial gaps in planning so you can fix them quickly. Incomplete product data sources, troublesome API connections, and legacy systems will require your effort (and frustration) – especially product data. In my experience, finding these issues in a discovery is far better than finding them unexpectedly later in a project.
Till next time.
-George
George Dzuricsko is Sitation’s Lead Solution Developer and double-certified as developer and implementations specialist with Akeneo.
