Please login or join to subscribe to this thread
Sounds like you could manage the project using an Agile methodology, however, you still need to define the MVP.
You are absolutely right to highlight the importance of the research and definition of the project - any objection to this should be treated as a high scoring risk, in my opinion.
Do you have any requirements or scope which can allow you to understand what the MVP can look like?
Ah that's a great way to represent the sponsor's request, to record any shortcut we take as risks.
This project is the very first attempt to establish the system. But from the get go, the system needs to be operational. Based on this, my understanding if the MVP is essentially the system itself. The system needs to do this (without going into a whole lot of details):
- allow user to deposit data
- allow broker to mediate that deposit (for legal reason)
- process the data and push it to two difference destinations
- security and legal concerns mandate that there is a whole lot of audit information and provenance tracking that goes on throughout this whole workflow.
The technical team pushes back on making isolated decisions on individual components without first understanding the big picture. I'm not sure how this system could be sliced and diced into something that could be developed Agile-y.
At some point, the work has to get started. We all know and recognize that no matter the amount of planning, things will undoubtedly change or not be what was expected. Get to a point of having enough to get started, while hashing out the remainder. Progressive elaboration if you will. If bringing an Agile approach into the organization, certainly could use the Scrum Framework if that fits the need. Either way, the important thing is to spend time on planning to be adaptable, then planning for rigidity.
Based on your knowledge at this stage, it certainly sounds like you need a system architecture, to show data relationships, User Interface, Integrations with external systems (if applicable) and a detailed list of the legal requirement and audit outputs. Workflow diagrams will be essential at an early stage.
No matter what approach you take in the methodology, whatever is produced needs to be able to be tested - 'user stories' and 'definition of done' in an Agile framework will allow this, even at a simplistic level.
Even with an adaptive lifecycle (e.g. agile), there is the need to explore candidate architectures to ensure that you don't build a "house of cards" by jumping right into development & testing.
I'd suggest trying to educate your sponsor using an analogy - would he be willing to have someone start work right away on a major renovation of his house without doing some due diligence up front?
Using an analogy is a great tactic. If your sponsor is not too technical, they can be blind to the complexities around a new system design. Putting the analogy into a context he/she understands will help.
Create a document stating the many risks of speeding through and analysis and design process, then present it to your sponsor to sign. I've found that many people who want to skip necessary steps in a project lose their eagerness to do so when you make them accountable for the outcome.
Can your team/stakeholders do the following:
- meet and identify high level functionality
- do some rapid prototyping of the major functions/interfaces
- once a prototype is approved, start developing; continue with additional prototypes
I'm not saying this is the right way to go; it's just what comes to mind when I think about your situation. However, I would also think about whether, or not, my team is capable of doing this.
It's easy to say "You need to use Agile," but if your team has never used an agile approach you may not want to introduce it on a high-pressure project. At least, not without training and maybe even a coach to keep the team on track and manage expectations of stakeholders and leadership.
Not all problems are the same, and likewise the solutions aren't either.
Analyzing a problem to-death before ever moving forward, or "Analysis Paralysis" is a common occurrence that many clients have encountered. Sometimes it truly is better to take the "Fail Early, Fail Often" mindset and start making early progress even though you don't know what the whole solution will look like yet. Sometimes that will steer the entire solution.
On the other hand, as Karl points out, you need an architecture to structure the project. That is the integration layer which establishes how the pieces fit together. Some architectures are more suited than others to change. A plug-and-play type architecture is designed around incorporating change, while a dedicated workstation type architecture is not.
While I often say that you don't have to be a technical expert to be a good project manager, understanding the architecture is critical as a PM to calibrate your GFI (Gut Feel Indicator) so that you can evaluate whether changes are easily absorbed, or require re-architecting the entire project.
One of the critical roles I play as a "technical PM" who's not an expert in the domain I'm managing is establishing which changes can be easily incorporated at any time, which have a set time-frame in which they must be incorporated or the collateral impacts drastically change the business case, and which changes we can only afford to make once.
My communication challenge with the customer is explaining the difference between changes which are invisible to cost and schedule within our business systems, and which changes require discarding work already completed and resetting the schedule and plan. Explaining to the customer how what they want translates into an impact to the project is not a trivial skill by any means.
Please login or join to reply