For the financial or budgetary side of a project there is a level of unpredictability that whilst not entirely underlying holds significance to the outcome of different areas that contribute greatly for the end result of the project. The financial side is so important that it is able to provide relatively crucial examples of causation towards different aspects of the project development that whilst varying in impact against the development of the project, all are centred around the same topic, that being money. Starting with the differences between the over and under (in a similar fashion to Time constraints) they however are different with how and what they affect in terms of the projects development, and the smaller elements that are involved with the bigger picture. Some of which are listed below.
Unexpected Costs: With ‘over’ it has a completely different meaning when compared to Time constraints as unlike the latter the ‘over’ in this sense is conveying when a project goes over budget instead of being given more of a budget than needed (in the context of more time). This is when the project development has exceeded a provided budget which can be brought on by different aspects of development that have either been unexpectedly changed, or required additional costs that weren’t originally anticipated (among other reasons). The reasoning as to why and how this would occurs begins with the Initiation/Requirements Analysis stage(s) of the project life cycle when the initial budget was agreed upon by the project manager and the client. During this time the software developers would be gathering information based on the necessary resources and equipment that they would require in order to complete the project to a satisfactory level. This information would of course be provided to the client as to establish the budget and regulation of payment (weekly, monthly, yearly) with it being documented and set in stone. This however contains a major flaw with the duration of time that is present between the agreement and the ending of RA/beginning of Design, within this time all of the elements mentioned previously would be arranged whilst adhering to the client-given budget. That time frame between the agreement (signing the project contract) and the beginning of actual development has the potential for having changes in the expected costs of different areas of the budget. For example when arranging to obtain the equipment and resources (Printers, Desktops, Other Hardware) their cost might of had an increase which would risk breaking the intended structure of the budget distribution, whilst not the most dangerous unexpected cost it is still significant when considering that when supplies and resources are acquired for a project’s development there are noticeable amount of people that are needing to be accounted for at once. Another more major example would be with the cost of the environment for project development, as it is very rare for a project to be developed within the same environment as the client for obvious reasons (available space, noise). The hiring of an office space is quite common but with any working environment or otherwise it is still considered space that is inhabitable meaning that the cost can be unpredictable, as it become a battle between managing the costs against the benefits, such as rent and electricity costs versus internet networking costs and space available.
Increase in Project Complexity: This is when the originally planned requirements for a project start to be modified with additional specifications and growth of the project scope. Since along with the previously mentioned Feature Creeping there would also be the potential for Scope Creeping, which works in the same sense that the scope itself is slowly but surely growing in size to the point where newer functions/features can be easily identified as disagreed requirements according the scope. Although the whole responsibility of the scope is to ensure that the client does not attempt to expand the project to unrealistic proportions there still can be client’s that hope to get the most out of this developing project as possible (as well as most client’s wouldn’t have all of their ideas compiled at once). Since Scope Creeping is very similar the FC it also contains the same looming issue that is overwhelming the developers with new requirements, the reason why this can be costly is both the amount of time it tacks onto the development cycle in Design & Implementation, but also the opportunity of compromising the standard requirements further complicating everything. This unfortunately is quite common in software and website development as mentioned beforehand the majority of possible clients out there are not 100% when it comes to providing in exact detail what they want as the end result.
Unforeseen Delay to the Project: Once again this is a topic that can’t be completely negated no matter who extensive and thorough you are, eventually there will some sort of set back to a varying degree (hindrance to complete project closure). Although with the previous two aspects discussed there is also the potential for the client to affect the project by causing a delay to a varying degree, along with the unforeseen setbacks that can stop forward progress with unexpected events and outcomes (such as the increase in cost for a resource). With the different ways in which a delay can occur it might initially seem as though there is no way in which they can be associated with each other, that is not entirely the case as the majority are classic examples of cause and effect (the relationship between the cause and effect involves an event where the effect is the direct result of the cause). An example could be something as simple as implementing a function into the software built to the requirements of the client as well, when introduced into the rest of the system in creates an issue where in which it might possibly clash with another component. For this example the implementation (cause) results in the in-progress prototype being hindered (effect) until the issue is resolved. That was only a minor example of what could slow down an application in terms of progress as there are more extreme causes and results that vary in severity. For a more extreme example being with the development team using the Waterfall method with a strict deadline (scenario) during the testing stage of the development life cycle there could be the discovery of a major glitch within the prototype that has compromised the entire software, in this situation with the amount of time against the chosen development model (against Waterfall’s rigidity)