Project Software and Identifying Stakeholders

- 1/20/2013 07:37:00 AM

Problems in Collecting Project Software and Identifying Stakeholders

Key stakeholders in any project are really the key to the successful management and valuing a software collecting project. At time stakeholders are left out of the project both in recognizing and utilizing. A stakeholder’s role is difficult to understand and this may cause the neglect.

Stakeholders in a project can be individuals who are directly or indirectly impacted by the project itself. Stake holders should be involved in the collecting process by using regular communications. Examples of individual stakeholders can be the owner of the software being used, the developers around the software and those who have bought into the project (Brugger, 2010).

There are group stakeholders that may be external or internal. A software development team who develops software for different departments is an internal stakeholder. If software being collected is to be commercialized, the pubic becomes an external stakeholder and may be consulted as the project commences.

Stakeholders are positive or negative. Positive stakeholders are those who will gain from the successful collection and completion of a project. Gain does not have to be financial but can be the end result of a mutual project.

Negative stakeholders are those who feel that the project would cause them to lose something. For example a software project that would streamline some processes and cause stakeholders to be laid off is a negative (Brugger, 2010).

Stakeholders inadvertently affect a projects objectives, policies or actions. Stakeholders may have differing views on how the project is collected, worked on and finished and their perceived responsibilities or expectations directly impact successful completion of any project. Stakeholders represent people and the infrastructure that is necessary to project development (Soliman, 2011).

There are times when key stakeholders are completely left out of any project including software collection and implementation. Ignoring stakeholders is usually not direct but can be the result of not being able to correctly identify stakeholders and the inability to realize that the user is the ultimate stakeholder.

In 2011 a group of security software developers began to collect and install the proper technology tools to run a security office, Company A. IT developed the hardware, installed the software and ramped up the systems. Everything worked perfectly according to plan.

However, the users or those who would actually run the day to day operations of the business by using the software were not consulted; they were left out of the equation. The result was utter chaos. The office and security staff had no idea why particular software was collected and developed, the concept behind the decisions and why they were to use this software. No amount of training could compensate for the lack of user stakeholders input.

To avoid delays in setting up systems it is necessary to engage the stakeholders. In the case of Company A the stakeholders were the users of the system. Several steps should have been taken to ensure the proper completion of the software project.

1.       Identify the stakeholders.
2.       Invite the users to development meetings and brainstorming sessions.
3.       Ensure that other key stakeholders are not left out by questioning everyone concerned.
4.       Use written records and population data to identify stakeholders
5.       Keep a written log that is easily accessible to all stakeholders concerning the development, problems, training, and set up of the equipment.
The most effective way of ensuring that all stakeholders are informed is full disclosure and communication (Chevalier, 2006).

References

· Chevalier, Jacques (2006). The Stakeholder/Social Information System [Online]. Available: www.cbnrm.net/pdf/chevalier_jm_001_sis.pdf [Accessed 16 January 2013].

· Soliman, Bryan (2011). Technical Articles, Stakeholders and Software Requirements [Online]. Available: http://bryansoliman.wordpress.com/2011/06/0/stakeholders-and-software-requirements/ .Last [Accessed 16 January 2013].

These are articles from my masters in software engineering classes.
Elad Shalom,
CTO at ITweetLive.com