Words: 2201
Key issues affecting projects and Project Management 1. Introduction Projects that have in their scope the exploitation of information and information technology as a mean of achieving development, have emerged in the past 50 years becoming one of the most frequent types of projects under development. But often, mistakenly, the developed software is thought to be the only product of such projects, and once they are completed, the project objectives are considered as fulfilled.
But especially in large and broad scoped initiatives, the development or acquisition of the IT software and infrastructure is only one subtask which should be driven by and integrated to the broader set of activities that constitute the whole strategic plan. The IT project management methodology is becoming more and more sophisticated and elaborated, and yet there is a very high rate of failures in IT projects. This paper aims to discuss some key issues which might underpin the success or failure of a project. The above will be discussed in the light of a real case example.
It regards a large company, a bank with a very large IT department, with a strategy that foresees in house development for IT applications. The bank expects to have significant cost cutting through in-house developments. At the same time it aims to achieve quality and flexibility through custom tailored, locally supported software. Recently there have been major changes in the way IT projects are managed. The changes have significantly contributed in a more consolidated methodology of managing projects and in improved efficiency.
Nevertheless new weak points have emerged which can probably be a result of process over-engineering. The discussion in this paper is mostly related to internal organization of projects inside a company; however most of the conclusions can also be applicable to a variety of scenarios. Let’s start with a short review of what were the initial process and the changes made to it, always trying to highlight some key practical issues. What can be some key characteristics that create inefficiencies, what can be the approach to olving them, what are the advantages and disadvantages of a “perfect” organization and fully standardized processes? 1. Initial approach The initial approach to project management was one with loosely defined processes. The necessity for IT projects was raised locally inside different departments, and with the support of the respective board member, this requirement would then be negotiated with the head of IT department who would then allocate resources after reconciling the project portfolio and the priorities given to each project.
Communication was frequent and lines of communication not strictly defined. After the project documentation was roughly completed and involved parties reached an agreement on timelines, the project was then assigned to specific resources considering their individual capabilities and the complexity of the project. The project team usually consisted of business representatives and developers. The chosen team or individual developer usually performed all tasks, such as understanding requirements and translating in IT language, software and database design, module development and testing.
After the development was completed the application was then handed over to the users for acceptance testing which was obtained through continuous negotiation and back and forth for further changes. [pic] Figure 1 ??? Initial approach to projects organization Initially there was a boost in process automations, with increasing attention drawn and more requests emerging. However problems were soon to appear. Before the actual changes to the project management approach, 99 % of the projects portfolio was in delay. Some of the main disadvantages and few advantages of the initial approach are listed below:
Drawbacks: – As some projects were initiated and followed by a single department, the solution was not appreciated by other organizational areas which work was to be affected, and they were only involved at the delivery phase. This caused partial redevelopments, and projects which ran out of time and budget. – Although many projects resulted in satisfied users, their cost of work was not justified by the benefits, at the eyes of higher management. – The initial scope of the project could have significant changes along the way, therefore distorting initial timelines and objectives. The ad-hoc management of projects caused overlapping of functionalities and poor integration between different applications – Resources were often moved from one project to the other, with new more urgent requests taking priority, leading to an inefficient use of resources – Some applications resulted of poor quality, and lacking integration with other systems. This became obvious only after some time that the application was in use. As there were no standard quality acceptance procedures, in some occasions the results were only tested at low level, without being approved by senior users. The project development was isolated to one or few developers and final applications were totally dependent on specific resources. There were no standardized engineering practices, and no means of sharing technical information. This caused major problems for the maintenance of these applications when these resources left the company. – The direct exposure of the developers to the “leadership” of business people, overcoming other important IT roles in the development, caused for some delivered projects to be with poor IT standards.
Advantages: – Flexibility, ad hoc requests could be satisfied very fast (sometimes very important requests came in ad hoc basis). – Important project were delivered when the appropriate conditions were created (team, motivation) – Anyone could have the name on success chart, motivated developers. – Developers gaining business understanding 2. Reformed approach The new approach is totally the opposite of the initial one, with strict processes and procedures in place, involving a far larger number of parties in the process.
A very important structure is created such as the Local Projects Steering Committee, consisting of major stakeholders and strategy makers, which will take up the responsibility for project approval and prioritization. A very important role during the changing process was attributed to the Project Office. So far its role was mainly related to the collection and keeping track of information. After the changes, the project office became the first screening point for any new project initiative. [pic] Figure 2 ??? New approach to IT projects organization The Projects Office role includes: Yearly planning with the all the bank’s areas for initiatives necessary to be implemented – Presentation of the existing project portfolio as well as new initiatives to the Local Projects Steering committee, for approval and prioritization. – Close collaboration with business for screening new project ideas and building correct business cases – Resources management – Coordinating process between all parties involved in a project for presenting and approving any deviation from the initial project scope to the Local Projects Steering committee. – Full documentation of each project phase
Reorganization is also made inside the IT department, where the business analysts took a much more active role than they previously had. They now act as the sole interface between IT and the rest of the company. Only the business analysts supply developers with information and feedback regarding requirements, changes, test results etc. Their role includes but is not limited to: – Update and maintain project portfolio within the IT department – Interpret business requirements and translate them into functional requirements – Work closely with all involved parties to enable their communication Follow up progress and keep track with milestones – Manage the project release process, ensure all stakeholders agree on the release IT has also split the roles between software architecture designers, developers, testers etc. For each project a separate sub-project is opened locally inside the IT department, and much wider teams then before are created. Advantages: – Project prioritization is in line with the overall strategy. This is ensured by the involvement of the Local Projects Steering Committee which includes representatives from the management board as well as department managers. Standard procedures enforce the involvement and agreement of all stakeholders during project initiation and signoff. – Clear project definition is enforced also, as the agreement of the project scope and measurable objectives is done during project approval. – Increased efficiency in the work of developers as now they can be committed in a longer term to a specific project without interruptions – Increase in the quality of deliverables, due to the creation of expert teams consisting of senior IT experts involved in architecture design, as well as a more organized approach to code writing. The solution is not anymore prone of a single developer, therefore avoiding excessive dependency on specific resources, which ensures software maintenance is not compromised – Transparent method of work and facilitated error tracking process Drawbacks: – Less flexibility in responding to ad hoc business requests, coming from immediate market and competitors movements. – Over-engineering the process; even simple solution will require it own time to be implemented – Difficult to reschedule resources in case of project re-prioritization – Sometimes overloaded teams are created. . Key practical issues related to IT projects After reviewing some symptoms of each of the approaches some conclusions are drawn related to the forces underpinning them. The following principles are pointed out as important factors to be incorporated in IT projects management strategy: – Prioritization of IT projects should be in line with the overall strategy, therefore should involve strategy makers Anything that does not help in the overall strategy gets a lower priority. Of course this cannot be decided in lower levels without involving those that make the strategy.
As a result it is very important to involve in the prioritization process representatives of the high management. This is achieved through the introduction of the Local Projects Steering Committee. – Identify all stakeholders prior to project start, involve them during the whole project life-cycle, and create a shared understanding of what and why it needs to be done. Already said in any project management book, however it came out as a strong necessity also in this specific occasion. Significant improvement related to stakeholder management is achieved after the implemented changes in the process. There should be a clear and agreed project definition. Space for flexibility should be given, but controlled in an organized manner. Balancing out these two is not an easy task. Although the business needs flexibility and fast response, a project needs to have clearly defined limits. However there should be a structured approach to modifying projects but not prohibitive to do so. The second approach addresses somehow this issue by enforcing that all parties agree and sign on the project scope and objectives in advance. However the procedures for possible changes are long and tedious. Team selection and management. Balance workload with an appropriate number of team members. Ensure the active involvement of field experts and senior IT experts. Keeping teams at limited numbers and carefully selecting capabilities needed, provide a solid basis for success. Teams with a small number of members tend to become overwhelmed, which is a characteristic of the first approach. On the other hand, when teams are large in number, members tend to take less responsibility, as it is often observed in the second approach. Focus on people motivation and team psychology. Beside the organics of the team, it is equally important to select the right people considering their motivations. Some important qualities to be considered could be: eagerness to learn and prove oneself, benefit from project results, team spirit etc. – Over organization and bureaucracy should be reduced to underpin a more flexible process. Agile project management methods must be introduced. “Keep it as simple as possible but not simpler”, Einstein. A minimalistic approach should be taken.
Maybe small projects do not need all the steps needed for a major one. A shorter path should be introduced for smaller projects. None of the approaches present an optimized combination of organization and flexibility. – Business minds and IT minds should be separated but a strong connecting interface should be introduced Besides responding to business requirements, there are other considerations that need to be taken from the IT side before mapping them to IT requirements. For this reason appropriate resources that can provide this interface should be included in the project team.
In the second approach, focus is put on the utilization of business analysts, which are intended to provide this interface. – There should be an integrated approach to systems development. IT infrastructure should be seen as a whole, unnecessary bricks should not be added. A centralized management of IT projects, as done in the second approach, would facilitate the IT department to maintain a holistic view over the entire IT systems, in order to avoid duplications, ensure integration between systems and keep data quality under control 4. Conclusion
The above example reveals two completely different strategies of project management. On one side, a simple, poorly organized but flexible approach, on the other a highly standardized approach with consolidated processes and clear roles. Certainly the latter approach is more advantageous since it imposes a higher level of organization and a more structured approach reflected in decrease of project failure and better delivery times. Nevertheless there are some values in the agile approach such as speed and flexibility which should be preserved.