These three constrains are stated as a triangle.. Some of the instructors call this iron triangle and some call the devil's triangle...
The task/presence of a project management is to save the project from inking into this devil's triangle.
When one of this trio changes, at least one of the remaining two is affected and the projects diverts. Project team and especially the project manager could not create a balance between these three, when the balance is broken the quality may go down and the satisafacion of the customer may be affected. For software and IT projects, scope is the most important factor in this triangle. Because cost and time of the project is determined by the scope. If the scope is not well-defined, the rest could fall down.
Scope effects analysis. Analysis shows us what the product or service will do at the end. Analysis of projects with outside resources are based on agreement analyses document and if there is any dispute about the scope this document is consulted. It is inevitable in the long term software projects that there will be change in requirement and applications, current legislation and therefore in the scope of the project. This change can be overcome with good management and risk management.
But the danger is a situation that is encountered if scope and analysis is not made accurately and fully. This is the difference between desired and required product and tested product. It will be more expensive to overcome this difference on the later stages of the project and it will effect the trust and belief of the shareholders.
Tricks of a Successful Analyst
- He/she should not underestimate the requirements of the customer and analysis process.
- Decreasing effort cost / price of the project should not be negotiated.
- Analysis process should be conducted by expert Business Analysts and consultants.
- The requirements should be described clear and in detail during the analysis process and terminological difference with the customer should be taken into account.
- Business Analysts should confirm what is told and should seek answers to "what should we do?", "how it should be done?" , "when?", "in what frequency?" ..
- Analysis document should be written in a clear and explicit languange and a common language should be used.
- Screen shots and processes (work flows) should be added to analysis document.
- Controls (date controls etc.) and constrains should be determined.
- For implementation part, difference analysis should be conducted at the beginning of the project.
- During adaptation main structure of the package should be intact and the changes should be in the boundaries of difference analysis (5% deviation).
- When the requirements are determined, general boundary of the project should be kept.
- Official approval of the shareholders should be taken for analysis document.
- For outside projects analysis document should be regarded as agreement and articles which will be consultant in case of disagreement should be prepared.