Project Management Central

Please login or join to subscribe to this thread
Project Sponsor wants to speed through analysis and design process
Network:20



Hello (new here!),

I'm in the middle of the analysis and design phase for a software development project. The system we are to deliver stretches from the UI frontend to archival backend and everything in between. In my limited experience, analyzing and designing a solution in which the whole team understands who all the pieces fits together and how each components contribute to the end goal is very important. I would think this process deservedly takes a decent amount of work and effort.

But our project sponsor disagrees and ask me to speed it up, leave some stones unturned and get on with development. He wants to have a project plan right away, with milestones and schedule defined. He wants to do this iterative manner, at the same time the entire system is supposed to be made available early next year.

My reaction to myself this is: We don't even know what are all the components that need to be implemented to support the vast pool of requirements yet. We don't also have prior experience to draw on to make guestimates.

I would appreciate your advice on what I could/should do appease our sponsor? Is his expectation reasonable? are there other approaches in developing project plan and schedule I could utilize to make project sponsor happy while allowing our team to do what they need to design something adequate?

Thanks for your help.
-H
Sort By:
Page: 1 2 next>
Network:82



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?
Network:20



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.
Network:2433



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.
Network:82



Hanh,

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.

Karl
Network:1708



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?

Kiron
...
1 reply by Karl Twort
Oct 09, 2019 7:34 AM
Karl Twort
...
Great advice from Kiron.

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.
Network:82



Oct 09, 2019 7:22 AM
Replying to Kiron Bondale
...
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?

Kiron
Great advice from Kiron.

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.
Network:649



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.
Network:886



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.
...
1 reply by Karl Twort
Oct 09, 2019 10:29 AM
Karl Twort
...
Just to confirm here - I didn't say categorically "Use Agile". I just commented that based on the limited information given, it seems the methodology could be applicable in this scenario.
Network:82



Oct 09, 2019 10:26 AM
Replying to Aaron Porter
...
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.
Just to confirm here - I didn't say categorically "Use Agile". I just commented that based on the limited information given, it seems the methodology could be applicable in this scenario.
...
1 reply by Aaron Porter
Oct 09, 2019 12:57 PM
Aaron Porter
...
No worries. You weren't the only person to mention agile, and I wasn't targeting anybody. I've led agile teams and believe in using the "right" approach for the work that needs to be done to achieve the desired results. I'm certainly not opposed to using an agile approach on a project, when it is the right approach. Team knowledge, organizational knowledge, and company culture are factors to be considered when agile processes are not already in place.

Good point about system architecture!
Network:365



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.
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"The illegal we do immediately. The unconstitutional takes a little longer."

- Henry Kissinger

ADVERTISEMENT

Sponsors