Requirements specification is the very foundation on which the edifice of the project is erected. Wrong or misinterpreted requirements can thus lead to a typical death march project. The ailments inflicting our public sector environment make requirements management a Herculean task.
The Ailments
Lack of Ownership and direction
IT projects in public sector are typically initiated by a central authority designated by the government. The end user management in many cases is oblivious of the need for the initiatives and hence it becomes difficult for them to spell out their IT needs in precise terms. When the task of stipulating the requirements is delegated to the technical staff they fail to see the entire canvas and steer the requirements according to their own whims. Since the decision makers rely on their technical staff for assessment and approval of the work done by the suppliers, the project may snow ball to a size manifold it’s originally envisaged size
Since IT initiative is viewed as a low priority business in the government departments and contribution of the staff towards requirements specification initiatives do not add any value to their visible professional performance, the concerned officials give time to the requirements gathering resources more as a matter of personal courtesy than as a matter of professional obligation. In some instances resources assigned for gathering requirements had to wait for several days before they were able to get some time from personnel busy in their routine tasks.
Legacy Systems
Existence of makeshift legacy systems can prove to be a stumbling block too. An organization might have a number of scattered standalone applications with inconsistent data on different platforms and systems to cater for individual needs of various offices. As the users model their business flow around these systems, they start viewing the newly initiated IT solution as next version of their existing systems and try to mould the requirements in a way that at the end of the day the model that emerges is an integrated replica of the existing sub systems which might or might not be the ideal solution
Resistance to change and fear of transparency
One of the reasons for lack of cooperation is resistance to change and fear of transparency. Source of much of the power wielded by lower and middle tier staff is their ownership and concealment of information. Since an IT solution capable of hierarchical and public reporting has the potential for making the information transparent it might be viewed as a demon bent upon snatching the power and authority away from the bureaucratic machinery.
Security Issues
Entry into client’s premises sometimes proves to be a major problem. Security passes are usually valid for a short span and much of the requirements collection team’s effort is wasted in maintaining the validity of the passes.
Confidentiality of information and artifacts
It is not uncommon for public sector officials to implicitly or explicitly refuse access to any information perceived confidential. It is impossible to talk about business process automation or reengineering when the existing process is kept hidden in shrouds of confidentiality. The situation worsens when an incomplete or erroneous process description is provided to hide a fact.
Clash of interests
As the benefits of the IT initiatives become visible to the middle level management they start perceiving it as a means towards increasing their power by manipulation of the ownership/ visibility of data across the departments. From the organizational perspective the requirements might turn out to be out of synch with the organization’s rules and stipulated work flow. If a desperate stake holder manages to get such requirements incorporated in the specifications, it might lead the project to a quagmire due to the resulting interdepartmental political standoff at a later stage.
Volatility of requirements
Volatility of requirements is yet another predicament. Since the end users usually have a very vague idea of their needs, they begin realizing the actual potential of the IT solution once they see the implementation. It is not uncommon for the public sector users to request a multitude of additional features after getting the release as per their original requirements. Yet another reason for volatility of requirements is lack of interdepartmental consensus on requirements due to clash of interests cited above and a limited posting tenure of the senior officers. To quote an example there was a requirement for production of Machine Readable Passports (MRP) in a public sector project. A lot of effort and time was invested in the venture and the performing organization successfully produced MRPs which were verified by NADRA. Much to the dismay of the excited development team, due to posting of a high level stakeholder the requirement was changed overnight to production of conventional passports.
While it is impossible to change the dynamics of the public sector mechanism, it is possible to adapt our project management practices to avoid the known pitfalls.
Ownership Leadership and Responsibility
Identification of a senior level owner and project sponsor in the end user’s organization is the most important factor in a public sector project.. Identification of a Senior Responsible Owner (SRO) in very initial stages can do wonders towards a projects success.
- A clearly outlined stipulation of the project objectives thus saving it from scope creep
- Contribution in requirement specification process becomes a professional obligation for the middle and lower levels
- Mitigation the difficulties associated with security and confidentiality of the artifacts
Prototyping and GUIs
Investing some time and effort on prototyping is usually more beneficial than trying to make the Requirement Specification documentation more precise, since the later might be treated by the end users as a formality and it might be impossible for them to visualize the scenarios and interfaces until they get to see it on the screen. Since typically much of the rework is required due to changes in the graphical interfaces (GUIs) than the actual functionality, it is a good idea to get the GUIs finalized before starting actual implementation.
Mapping Existing Business Processes
It is generally expedient to directly map their existing business process in the automation, because an attempt to reengineer the basic flows might get accepted but most likely it would render the solution unacceptable later when it is actually used. In case of any apparent discrepancy regarding requirements given, officially published rules of business and official instructions manuals should be consulted and matter should be escalated where pertinent
Modular Approach
A key characteristic of the public sector projects is their size and complexity. No matter how well a public sector project is planned, the peculiarities cited above will ultimately drag it towards chaos. The best practice in this scenario would be visualizing the project as a collection of several small projects (chunks) and managing and delivering the chunks instead of trying to manage and deliver the project in its entirety. The feedback from a delivered module can help in further refinement of the understanding of requirements for rest of the modules
Posts
No comments:
Post a Comment