Hanh VuPrincipal Project Manager| solo.ioChurchville, Md, United States
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?
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.
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! Saving Changes...
If you are the PM then your responsibility is to be transparent with the sponsor. You have several approaches at your disposal. In your situation, here are a few. 1 - Assumptions. You need to list all the assumptions that you believe are or should be in place (like the components you mentioned). 2 - Risks/Issues. From your own example, one big risk would be "lacking components needed to support requirements", and then for that and other risks, assign your probability and impact score, which I would think would be very high risk (red color). In the Impact section of that risk item, you might mention things like reduced quality, customer dissatisfaction, delays to the project. 3 - Sponsor decides risk action. Very important. Once you have identified assumptions, risks and assigned the threat level place, document it, then have your sponsor select/signoff to either accept the risks or implement the method to mitigate or eliminate the risk, which I would assume would be to incorporate the components that you mentioned. If you don't do these things and the project fails, your sponsor may have a short memory and shift the blame to you. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
There is a rule that from more than 40 years it has been proven: 40-20-40 rule. You can find more detail inside Brooks´s book "The mytical month-man". The way you distribute the percentage depends on your life cycle. 40% for analyis and design, 20% for construction, 40% for validation and implementation. Saving Changes...
Hanh VuPrincipal Project Manager| solo.ioChurchville, Md, United States
Thank you all fo you advices. There are quite a bits of take away and confirmation that will help me navigate this situation with our sponsor.
I wasn't aware of the 40-20-40 rule, but all of my experience in software development agrees. It would make a strong argument for giving this analysis and design phase the effort it deserves. If sponsor persists in his request to expedite the process, treating my compliance to the request as risks and document assumptions would make me feel more sane about it.
We are indeed in the midst of designing a system architecture, on which I can structure the project. This is an important foundation block in my view. But I wasn't sure if this was because I'm just not aware of other approaches. The time line and resources we have don't allow us to churn out prototypes iteratively, I believe.
This is very helpful. Thanks again! Saving Changes...
What you are describing here are technical issues. Are you a technical expert in software developing (software developer, architect, business analyst)? If not you should not make such assumptions.
The experts in the domain should advise the sponsor and not people who have limited knowledge. As a PM with no domain knowledge you should just facilitate the decision making process. What are the people that are currently working on the project say about this?
Anyway, from my experience at least, almost all the software development projects are delivered late and over budget, the business analysts, software architects and developers are powerless to do anything about this and the PMs even more powerless. You can do a brilliant job as a PM but your project would still be late you have very little control.
If your sponsor has experience in such projects he probably knows that his project would be late anyway and does not want to make it even longer by prolonging the analyses phase.
Agile in theory could help but from my experience it makes things worse as customers in most cases really want waterfall, having everything planned from the beginning and delivered in one-go. If changes are needed they are managed with change requests.
Also with Agile there is a high risk of failure as the users may never stop on asking for features at the end of every iteration and the sponsor may end up without money for the project. I have seen this happening.
...
1 reply by Hanh Vu
Oct 10, 2019 5:33 AM
Hanh Vu
...
I have a BS in Computer Science and was a software developer for 8 years before i decided for jump ship :). I only manage software development projects in the same domain. For all projects i manage so far I am both the PM and the BA.
It's nice to know that "almost all the software development projects are delivered late and over budget", because my last 3 projects have not been. I must have done something ok. it helps with predictability when I get to work with the same team, in the same env over and same domain over and over, just different applications.
I'm not entirely sure why my sponsor is showing this level of anxiety. He's been attending open source conferences, in which he hears about how big open source foundations manage their software development project. This could have something to do with it.
Saving Changes...
Hanh VuPrincipal Project Manager| solo.ioChurchville, Md, United States
Oct 10, 2019 3:16 AM
Replying to Adrian Carlogea
...
What you are describing here are technical issues. Are you a technical expert in software developing (software developer, architect, business analyst)? If not you should not make such assumptions.
The experts in the domain should advise the sponsor and not people who have limited knowledge. As a PM with no domain knowledge you should just facilitate the decision making process. What are the people that are currently working on the project say about this?
Anyway, from my experience at least, almost all the software development projects are delivered late and over budget, the business analysts, software architects and developers are powerless to do anything about this and the PMs even more powerless. You can do a brilliant job as a PM but your project would still be late you have very little control.
If your sponsor has experience in such projects he probably knows that his project would be late anyway and does not want to make it even longer by prolonging the analyses phase.
Agile in theory could help but from my experience it makes things worse as customers in most cases really want waterfall, having everything planned from the beginning and delivered in one-go. If changes are needed they are managed with change requests.
Also with Agile there is a high risk of failure as the users may never stop on asking for features at the end of every iteration and the sponsor may end up without money for the project. I have seen this happening.
I have a BS in Computer Science and was a software developer for 8 years before i decided for jump ship :). I only manage software development projects in the same domain. For all projects i manage so far I am both the PM and the BA.
It's nice to know that "almost all the software development projects are delivered late and over budget", because my last 3 projects have not been. I must have done something ok. it helps with predictability when I get to work with the same team, in the same env over and same domain over and over, just different applications.
I'm not entirely sure why my sponsor is showing this level of anxiety. He's been attending open source conferences, in which he hears about how big open source foundations manage their software development project. This could have something to do with it.
...
1 reply by Adrian Carlogea
Oct 10, 2019 6:40 PM
Adrian Carlogea
...
Thank you for your message.
Having such an experience makes you the perfect candidate to advise the sponsor regarding what he should do to have the best outcome possible.
However managers serving as project sponsors primarily think in terms of money and they try their best to pay as little as possible. I think you should try to convince him that allowing the team to spend more time on analyses and design would result in less money spent as this would make the development easier.
If the above is not true and he only cares about money then it would be harder to convince him that what you are proposing would bring more benefits.
His experience owning software projects is also important. If things don't go as planned he may be prepared to spend less and reduce the features just to save money. You must adapt to his ways of thinking.
Congratulation for your projects I personally have never seen a project to complete according to the original plan. This does not mean that the projects on which I have worked have failed they just needed a change of plan that involved more money being spent or reduction of scope.
If money is what he is looking after I don't think Agile would help, on the contrary this could make the project take longer and cost more. One of the problems with Agile is that users always want changes and new features without caring too much about the limited resources. The sponsor on the other does care about resources.
I have a BS in Computer Science and was a software developer for 8 years before i decided for jump ship :). I only manage software development projects in the same domain. For all projects i manage so far I am both the PM and the BA.
It's nice to know that "almost all the software development projects are delivered late and over budget", because my last 3 projects have not been. I must have done something ok. it helps with predictability when I get to work with the same team, in the same env over and same domain over and over, just different applications.
I'm not entirely sure why my sponsor is showing this level of anxiety. He's been attending open source conferences, in which he hears about how big open source foundations manage their software development project. This could have something to do with it.
Thank you for your message.
Having such an experience makes you the perfect candidate to advise the sponsor regarding what he should do to have the best outcome possible.
However managers serving as project sponsors primarily think in terms of money and they try their best to pay as little as possible. I think you should try to convince him that allowing the team to spend more time on analyses and design would result in less money spent as this would make the development easier.
If the above is not true and he only cares about money then it would be harder to convince him that what you are proposing would bring more benefits.
His experience owning software projects is also important. If things don't go as planned he may be prepared to spend less and reduce the features just to save money. You must adapt to his ways of thinking.
Congratulation for your projects I personally have never seen a project to complete according to the original plan. This does not mean that the projects on which I have worked have failed they just needed a change of plan that involved more money being spent or reduction of scope.
If money is what he is looking after I don't think Agile would help, on the contrary this could make the project take longer and cost more. One of the problems with Agile is that users always want changes and new features without caring too much about the limited resources. The sponsor on the other does care about resources. Saving Changes...
Hanh VuPrincipal Project Manager| solo.ioChurchville, Md, United States
I"m happy to report that the concept of MVP really resonate with our sponsor and my team. It calms the sponsor's anxiety about my team spending too much time chasing unicorn solution. And it focuses the team's attention to the core of the system while giving them the space to architect the infrastructure adequately. The 40-20-40 rule has served as a good talking point, as well as a reminder to gauging progress.
thank you all for your help and advice. Saving Changes...
Community Champion
