requirements change.....
Requirements are supposed to change, else there will be no market.
But when you are involved with the client to formulate the Project which has to be 'developed and released', you try to cover all the important specs related to 'development and release'.
In this era, mostly people can be seen to opt for IaaS, PaaS solutions for their production release (and for development depending on budget).
There are lots of Organizations, who have had their own SysAdmin Team for years for years and have more faith on them for cheaper, better, secure, and/or conrolled environment.
Then there are also projects that need to be on internal organizational networks due to some internal boxe-d service or company policies.
Either way, initially there can be two situations. They will have an idea about where they want it implemented, or not.
If they decide, you know better. It's better. You come up with the best suited solution respective to projected requirement. And get a yes from them.
If they decide to drive the decision. Even more better. Now analyze the solution, and project the respective pros, cons and the patch-y aid that will be required. Get them to agree with approach that wouldn't make the project-life a hell.
It needed to be done at start, once you start with project..... these will only slow you down and 'slum your time' once you are deciding it post-project-inception.
Requirements are supposed to change, else there will be no market.
But when you are involved with the client to formulate the Project which has to be 'developed and released', you try to cover all the important specs related to 'development and release'.
In this era, mostly people can be seen to opt for IaaS, PaaS solutions for their production release (and for development depending on budget).
There are lots of Organizations, who have had their own SysAdmin Team for years for years and have more faith on them for cheaper, better, secure, and/or conrolled environment.
Then there are also projects that need to be on internal organizational networks due to some internal boxe-d service or company policies.
Either way, initially there can be two situations. They will have an idea about where they want it implemented, or not.
If they decide, you know better. It's better. You come up with the best suited solution respective to projected requirement. And get a yes from them.
If they decide to drive the decision. Even more better. Now analyze the solution, and project the respective pros, cons and the patch-y aid that will be required. Get them to agree with approach that wouldn't make the project-life a hell.
It needed to be done at start, once you start with project..... these will only slow you down and 'slum your time' once you are deciding it post-project-inception.
No comments:
Post a Comment