COEPD – Center of Excellence for Professional Development Happy Learning
What is a constraint? And how can a software project have any constraints, even when we are willing to use state-of-the-art technology and hire the best people, right? Well, this is the ideal scenario we are talking about which, in the real world, doesn’t quite exist. Any software project is undertaken to ultimately achieve a final goal – building software to automate our manual work. Furthermore, this project will fall into one of the main three categories: a desktop application, a web-based application or a mobile application. Moving further, all these ‘types’ of software, based on their area of expertise, will have certain limitations. In the layman language, the all these three categories of software will not be able to do certain things and will have these ‘limitations’. It is not only about the functionality of the software, these shortcomings may also be related to other factors involved in the software’s development which directly affect the project.
These influential factors, or these project constraints, are to be necessarily considered before we start the software development. These constraints come into picture based on the project scope. As a side-benefit, we want to build a fully functional software application and avoid a scope-creep, as we definitely do not want to go for gold-plating. Nevertheless, we need to keep these constraints at the back of our mind. Let us dive further into what these constraints are and how they can possibly affect our project at the surface, or fatally.
A stakeholder’s first and foremost concern in any software being built, is the money involved, because at the end, the profit is the main objective. So this can be considered to be one of the main constraints in a project – the project budget. Based on the project scope, the project budget is pre-decided and funds are allocated accordingly. This will differ, based on the type of project – for a FP(Fixed Priced) project, the funds are allocated at the start and won’t be extended, unless it is an exception being made. For T&M(Time and Money) projects, the funds will usually be allocated at the end – based on the timesheets submitted, which show the man-hours against the work done. But here, the constraint is, that in the event of a scope creep, i.e., the project going out of scope or some additional functionalities being built as the result of a Change Request, the budget will have to be extended and more funds will have to be allocated for the same. This change in the project should only be incorporated if : (i) It does not increase the project budget to almost double the cost incurred and (ii) if it does not affect the other two main project constraints – the scope and the schedule.
The send most influential constraint is the project scope. Every project manager would dream of an ideal scope, in the ideal time, with many skilled resources. This, unfortunately, cannot be granted in most of the software projects. After initially gathering the project requirements from the client, the scope of the project is determined from the problem statement. Even if the client has not explicitly stated the project’s limits, the Business Analyst will have the boundaries defined and established by multiple interactions with the client. Finally, at the time of the project sign-off, when the client given a green signal, the project’s scope will be properly embedded in the minds of every stakeholder involved. The project’s scope cannot be exceeded and even if we are doing the client an extra favor, we simply cannot go outside what was initially decided. This most definitely affects the software and its overall development.
Finally, we have the project to be completed, with a well-defined project schedule for the project to be completed in its entirety. Many things may go wrong with the project’s pre-defined schedule, adhering to the SDLC (Software Development Life Cycle). Right from the project’s inception, till the project closure, all the stages and milestones are defined at the beginning, which may be outlined in the Kick-off Meeting Report. This is at the very heart of the project’s concern, as any change in the schedule of a project will directly affect the milestone next to it and will result in a major effect to the timely achievement of the project. Also, as per the schedule defined for the project, the resources are chosen and if there is a hindrance in the schedule, it may generate a requirement of more resources. But here, the project’s schedule may be affected due to many things – bugs in the system, lack of resources, lack of technical knowledge and know-how, etc. And once the project’s resources have been decided, the action of altering the schedule has to go through a pre-defined approval process. It does not matter even if we claim to be Agile in our approach – a change in the schedule is never predictable nor can be avoided: it has to be incorporated, if feasible.
Additionally, there are some other factors which can serve as constraints in the project – the risk and the quality. These also are important for the project to a much greater extent in some ways. The risk analysis has to be essentially performed at the beginning of the project so that the risks can be avoided and also, it has to be ensured that the project’s quality is not affected, as it is like the face of an organization and its growth.
Though these project constraints are limitations of the project, they can be turned into the project’s positive building factors and can also serve as the basis of a project’s overall success. By building a software of the right scope in the right time, with the right number of resources and the right well-defined schedule, we achieve the right thing – a happy and satisfied client!!!
References:
- https://whatis.techtarget.com/definition/constraint-project-constraint
- https://www.workfront.com/blog/the-6-project-constraints
