An Unidentified Working Project

Projects come in all shapes and sizes, and being able identify when something that you are working on is actually a project is extremely important. Far too frequently projects have failed due to the fact that when they started, they were not viewed as projects. It could be an individual or a small group in the process of creating a mini-application or ‘prototype’ that then gains attention or traction from management. There is a strong temptation in this case to continue to build off what has already been created, as going back is seen as a waste of time. This is very dangerous. Planning is vital, and generally individuals do not properly plan out their own test cases. Much of the existing development could potentially be reused, but only if it is deemed in the long-term interest of the project’s success.

This method of development is sometimes seen as organic, as though it has grown dynamically out of the business, a beacon of innovation and foresight. It is true that it can foster innovation, but these initiatives can quickly turn into research projects if not properly controlled. A strict set of requirements, deadlines and scope need to be identified to ensure that what is being developed is in fact what the business actually needs.

So how do we know whether a small initiative is going to grow into a full-blown project? I would suggest that the key aspects of what you are working on are closely monitored. Below I have outlined some key areas to be aware of.

Budget: If a significant percentage of your budget is being used on a particular task, then it could be elevated to project status. Also if you foresee an increase in capital expenditure, then this will need to be managed.

Time: Are you using up an ever-increasing amount of people’s time? This is very similar to budget, as budget can often be measured in FTE. Remember that the least number of people you need to run a project is two, as one person should be directing, while the other manages the delivery of the project. One person can never properly manage/direct himself effectively.

Impact: Does this task require input from other departments? If so, then you will most likely need buy-in from senior management to drive the initiative transversally across different departments. This will require investment in ‘political capital’ to ensure success of the initiative.

Risk: If at any point you feel that what you are working on now involves an elevated level of risk that requires some form of management. Ask yourself, if we were to stop this task, would it affect our day-to-day operations?

Prepared by M. E.

Requirement Gathering under Pressure

Requirement gathering is a crucial step for a project and especially an IT project to succeed. Without a detailed understanding of what the requirements and accordingly the corresponding functions and features of the output are, the project is likely to fail. We all know this pictures that show what can become out of a tire on a rope hanging down a tree, if requirements are not clearly defined; therefore most of the project manager undertake thorough requirement gathering activities. Although every good project manager knows about the importance of getting the requirements right, how is it possible that still project fail due to lack of understanding of the requirements?

My answer is that in those projects time was an issue and project manager had to race through the process of gathering due to executive pressure. Executives always want to see progress, but progress in an IT project often means lines of code or finished features. Unfortunately, no code is generated during the requirement gathering process; therefore it is hardly seen as progress. The worst situation are those were the sponsor thinks he knows the requirements and hence doesn’t see any necessity for requirement gathering at all. I have recently been in a situation like that, were a project almost failed, because of the sponsor’s actions during the requirement gathering. Fortunately, we were still able to make the project a success. In the following I will describe the situation, why the project could have failed and how we turned it around.

An executive came to our team with a project suggestion. He had an idea for a project in a department that wasn’t his, but he was convinced that they would need that software he had in mind. Because it sounded like an interesting project, we took it. After our first meeting with our customer it was clear that there hasn’t been a business case, since the project was just based on the idea of the sponsor. Our sponsor was a powerful person in the company so that we and our customer were forced to start the project, although we were hesitant to do so without a business case. We tried to create a business case to get the requirements clear, but none of our customer had a clear picture of what was exactly needed. So we arranged a meeting with our sponsor and our customer either to get our requirements right (We have prepared a process map to find the activities where the proposed software would be helpful) or to stop the project. Unfortunately neither happened, because our sponsor dictated the requirements and the users were afraid to disagree with him. Although we were not convinced that those were the needed requirements, we had to move on due and start developing the software. We were right and the actions of our sponsor made us almost miss the deadline due to scope changes in the middle of the project.

In IT projects a close collaboration between the project team and the users is important to be able to check if requirements were translated into the right features and functions. Because we anticipated that the requirements might have been wrong, we intensified the collaboration with the users in order to discover development of none valuable functions immediately. As a consequence we experienced a rolling scope change, that is, many incremental changes that minimize the wasted time, but lead eventually to a big change in the requirements.

Our sponsor agreed with all the changes in the scope, since his ultimate goal was to make the user happy; however his actions almost made the project fail. The lessons learned is that you should never start a project were the requirements are unclear or pushed onto the users from top management, because the actions we took to rescue the project are not possible in every environment.

Prepared by Peter

Personal PM Story:

I was previously involved in an IT project for a large financial institution which I will call ABC Company due to potentially sensitive information. I was part of a consulting team that was responsible for gathering and analyzing business needs requirements that will feed into the design of the IT system. The project started in 2010, and was scheduled for implementation in 2011, but by the time I left the team late 2012, the status of the project was still unknown. The project management team could not provide any information on the progress or the completion date. Executive management had shifted all attention to this project because it was consuming enormous amounts of funding, but also disrupting business operations.

The old legacy IT system currently being used was extremely old and lacks the functions and capabilities required for the complexity of today’s banking needs. Many of the problems with the old IT system were not fixed because everyone anticipated that the new IT system would replace it. Instead, temporary patch fixes were used to “band-aid” the problem until the new IT system is in place. As the new system becomes delayed, these band-aids are causing even more problems. This is a common problem with time overrun in IT projects.

One of the biggest problems I could see from my role was the lack of collaboration across departments. The IT department had traditionally been highly independent and sees themselves as more of an external service provider rather than a part of the company. As a result, a tremendous amount of time was “wasted in the fuzzy front end” of the project trying to coordinate meetings and agreement on the scope.

The other problems I saw are very similar to those in the London Stock Exchange Taraus project. The complexity of the IT system is significantly higher than expected. Constant scope and feature creep. Our consulting was asked to provide business needs assessment very early in the project, but was asked to provide a new assessment several more times as scope changed throughout the project.  It is remarkable to see how companies still face these problems even though the project management discipline has been fairly refined and well developed over the last few decades.

Prepared by EL

The Futility of IT Project Management

I find the success rate of large-scale IT projects astonishing. As discussed in class any project with a budget greater than $3M or in the works for more than 18 months is almost guaranteed to fail. It would seem that getting 40+ people to work towards a common IT-related goal and complete it on-time, on-budget and to spec is nearly impossible. Should the project be even bigger and more crucially important to the success of a firm, it will have absolutely no chance of successfully being completed on time, budget or to spec.

Regular, non-IT related projects do not suffer this same dismal success rate. Skyscrapers are built all the time, using hundreds of talented construction workers from dozens of trades and they are easily able to forecast timelines and costs while building exactly to architectural plans. In comparison with the IT industry the construction industry can also boast projects that last years and costs billions. Yet if every time a major casino was built of the Las Vegas strip it was guaranteed to take 5 years longer than expected and cost two to three times as much as forecasted our world be devoid of super-structures.

To an outsider it could be said that the construction industry is a much simpler list of trades, and that a professional dry wall installer doesn’t have nearly as tough of a job as does a graphic designer. However managing hundreds of dry walling professionals would come with its own challenges, in general these are uneducated professionals with significantly varying levels of professional conduct. Further while some trades like installing dry wall are relatively simple, the time and effort required to plan and execute a major structure’s plumbing and electricity are enormously complex. Yet again, the construction industry is managed with a completely different set of expectations.

One could argue that the reason for IT Project Management’s dismal track record is the consistent innovation that is attempted in this sector. So rarely are major projects with hundreds of programmers working on any type of project that has been done before and as such they cannot so accurately forecast their timelines or costs, further they can’t build out an architectural plan nearly as precisely. However I still believe that IT project managers could learn a few things from the far less sophisticated construction industry.

In the construction industry when a major construction project is planned there are massive teams of engineers and architects scouring over every detail of the plan. They then bring the project plans to specialist engineers with experience in planning electrical and plumbing and then modify the plans accordingly. Every major detail of the structure is planned years before ground is broken, then small scale models are created of the expected final project. Stakeholders are consulted, needs and requirements are noted, then they are integrated into the plan and finally reviewed. While small changes are much more easily managed, and don’t necessarily have greater ramifications on the rest of the construction the later changes are generally cosmetic, rather than structural. The construction of a 60 story skyscraper would never get 35 stories high before the owners decided that it should actually grow to 80 stories. Yet, in IT project management such monstrous structural changes seem to be acceptable. When a project is 40% completed and only small cosmetic modifications are realistic, it still seems to be common place for major companies to change their desires for an end product and demand conformity from their team.

The other area where I believe construction projects seem to have a leg up is the vast number of project managers that are on site at any given time. Every worker on a project can expect that at some point, almost every single day, someone is going to walk by and see what they are working on, how their work looks and whether or not it is up to code. On the contrary, because programmers are so highly educated, because they are designing something new and since there is no code to follow, they are given a large amount of trust to complete their projects and submit them at a specified date. In projects with several thousand programmers, each with their own little computer screen which is hard to walk past and casually inspect, there is an incentive for programmers to pretend to be working. There are enough other programmers that are also working on debugging code or creating graphics, that it is easy to put your head down and take a lazy day every now and then. While it may hurt morale, perhaps a shorter leash and more frequent checks of output would help major IT projects move forward in a more timely fashion.

Prepared by AI

Project Failure Reason

When we think of reasons for project failure and search the very trusted net, a number of reasons pop up. They can be broadly classified into the following four categories:
- People related
- Process related
- Product related
- Technology related

A number of issues and challenges need to be addressed in order for successful management and delivery of the project. In this blog post, I will be sharing a personal experience regarding the importance of stakeholders in the effective development and completion of a product/ project.
Being from IT background myself, I have seen and experienced a number of reasons responsible for failure of different projects. Reasons ranging from some general issues like lack of motivation of the resources or some unidentified risk etc or some very specific concerns like lack of expertise, budget constraints or lack of processes and procedures etc. However, the reason that I would be discussing in this post is how a project failed because of the lack of involvement of the stakeholders i.e. the end users.

I was part of a ten-member team working on a project for an internal client, wherein the product was to be used and implemented within the client’s department. Since, the beginning of the project this client was the single point of contact for the team. However, he was not the only stakeholder involved and this product was to be used by many more people. Like for any IT project all the necessary procedures were taken into consideration and the necessary steps performed. The requirements were gathered and analyzed and the feasibility study was conducted. Later, the development and the testing were done. Along with these steps the documentation was completed and the processes were followed. However, on the date of delivery, over a conference call, it was not only the client that was present but also the intended users. The discussion that followed was not very encouraging either for the end users or for the team. As the conversation began the team realized that the stakeholders expectations were different from the requirements specified to the team. It was recognized that in order to complete those expectations it would require a considerable amount of time and effort from the team. As a result at the end of the conversation this project was scrapped. At the end of it there are a number of questions that rose - What if this was not an internal project? What if the scope of the project was larger? What if the organization’s reputation was at stake? Could then we afford such a shortcoming? The answer probably is – NO. The basic learning from this project is that
- Stakeholder involvement is utmost important for the success of the project.
- Not only the developing team should be clear of the expectations, but also the different stakeholders should be on the same page.

Prepared by NG

Managing Employees in IT Project Management

Human resources are an integral part of any IT project. They provide the knowledge capital and also execute the design, implementation, test and maintenance of the code. It is a largely dynamic resource and provides its own challenges and opportunities. The IT project manager needs to understand its nuances and manage it well to be productive for the organization.

There are several issues that need consideration for managing employee relations. The project manager needs to be sensitive towards them and manage them so that employee morale is maintained and issues are handled diligently. We can look at some issues and approaches that can be taken by the PM to promote healthy team environment while being effective.

a. Employees with pride issues
Due to prior work experience, university background, technical knowledge or any other motivators, certain employees consider themselves superior to others. This causes rift between teams wherein other members do not feel comfortable in interacting with them. There may be occasion of rude behavior, not helping team mates, not doing a work considered to be “too simple job” etc. A PM’s responsibility is to pitch in such cases and talk to the employee. As a key stakeholder in the overall IT cycle, the PM is responsible to let the problem employee know that teamwork is far superior to mere individual contribution, and get him in line. Great projects work when all stakeholders have involvement and dedication to it.

b. Managing employees with anger issues
Employees with anger issues can cause low productivity, stress, lack of dedication and unpalatable working atmosphere in the office. The PM should step up in this case and hold a conversation with the employee. In such cases, the employee should be made aware of the importance of being cordial in office relationships. The manager can also recommend some personality development sessions and training for the employee.

c. Tackling employees with work avoidance habits
The PM needs to look out for employees with work avoidance habits. These employees try to stretch work by doing it slowly and avoid taking additional responsibilities. The PM should use KPI to measure the employee performance. It should be communicated clearly to the employee that shunning work adversely affects her career growth opportunities. Making processes for tracking and periodic feedback is a responsibility of the PM for the resources reporting under him.

d. The lone rangers
Lone rangers are employees that are great as individual contributors and do not prefer to work in a team environment. The PM should make sure that this should not go out of hand. As a successful IT project involves ample group work, lone rangers should learn to be team players as well. Devising incentive schemes that involve peer reviews, 360 degree feedback etc. makes the employee dependent on its peers for feedback. By tying incentives to team work, they provide incentive to the employee to work in a group and foster relationships with the co-employees.

e. Sexual harassment challenges within team
Sexual harassment within team is a grave issue that sometimes challenges the PM. Once such an issue is brought to his notice, the PM should hold conversations with all the parties involved. Then depending upon the issue, the PM may choose to step in and warn the culprit of official action. The PM may also forward the matter to the HR department for their support and policy.

f. Promotion aspirations of team members
Handling the promotional aspirations of the team members is a difficult task. Every employee seeks career growth in the company. The PM should chart out the career growth path for his resources and tie it to the SMART goals. The SMART goals are MBO (Management by Objectives) technique that set goals for employees that are Specific, Measurable, Achievable, Realistic and Time bound. As the employee sets out to achieve these goals, the manager should periodically apprise them of their status and help in course corrections.

g. Aspiring employees to skill upgrade
Organizational success of employees is also dependent upon them updating their skills with the changing times. It is important that the PM motivates all its project members to keep updating their technical and business skills in accordance to changing project demands. The employee incentives can also be tied up with them going for learning new tools, attending a workshop, learning a new language, implementing a mini project etc. In regular meetings with the project members, the PM should assess their individual career aspirations and help them identify skills they would want to develop upon.

h. Handling leaves
Managing employee leaves is something that every PM comes across. Clear policies for leave management should be set up in place. Also the PM should think about backup resources before granting leave to any employee. There should be enough resources available such that the work in the project does not get stalled due to any employee taking leave and no one to fill in the absence.

i. Building channels within team
The PM should act as a channel between teams. He should act as a facilitator for inter team interaction. This is essential in a large organization wherein there are multiple teams involved in complex projects. Facilitation includes building communication links with the other managers, helping in identifying resources in the other teams that would provide the needed information, managing approvals to gain access to information etc.

j. Power distance while being approachable
It is important for the PM to maintain a degree of power distance with the team members. This would help him gain respect, support and have a degree of control on the teams. While this is important, the PM should also be approachable. He should allocate time for his resources based upon prior appointments. He should be a mentor for the team but does not need to involve himself in all the team’s activities. The PM is like the coach of a team.  He involves in the team, guides it, mentors it and speaks on its behalf; but does not do the actual playing.

Prepared by A. Singh

PM in ABC

ABC* recruited me for one of its most troubled projects called “SOS”. SOS problems tarted from inadequate project planning and management which trickled down from development team to testing team, end users and hence to 24*7 “Production Support team (PST)”, where I was deployed.
PST was facing different problems because of lack of project management methodologies implemented by ABC as summarized below.

1. Ambiguous Scope: Major issue for PST team was that management didn’t developed project charter to clearly define the scope, especially responsibilities of PST team. As per PST management, PST was only supposed to provide temporary fixes of issues, but not responsible for maintenance of codes which should be handled by development and maintenance (D&M) team. But D&M team thinks otherwise. In short, it was not clear to what extent PST was responsible for maintaining the codes leading to confusion, politics, delay in providing permanent fixes and customer dissatisfaction.

2. Lack of Processes: Within PST team, Processes were not well defined. For example, there was not any formal process for new issue assignment. Many team members used to start working on same issue leading to redundancy and inefficiency. Secondly, there was no standard documentation process because of which PST team was unable to develop strong knowledge database (KB). Because of lack of KB, team was reinventing the wheel every time resulting in slow issue resolution and additional cost for ABC.

3. Lack of clear role definition: Because of lack of project charter, there was confusion on roles and authorities of different team members which was leading to power politics, adding to employee dissatisfaction. Most of the time was spent on assigning issues to one another, without any formal authority, leading to inefficiency and delay in providing deliverables to customers.

4. Unrealistic expectations: Because of lack of implementation of project management methodologies related to project scoping, scheduling and resource assessment, Management committed to resolve unrealistic number of issues per day. It completely ignored the factor that most of the PST is new and is in beginning of learning curve, no formal training or knowledge transfer sessions were conducted to teach the team and there is shortage of skills and resources.

Because of lack of implementation of project management methodologies as described above, Project ran into problems like high attrition rate, and high number of service level agreement (SLAs) non-compliance etc.

Recommendations:

1. ABC top management must come up with formal project charter for PST defining its roles and scope to avoid ambiguity over issues being handled by it. It should be clearly communicated to PST and involved stakeholders.

2. Project Charter also must define clear authority and roles of team members to avoid politics and confusion.

3. Within project, PST should implement project management methodologies to formally develop the process and to implement them to reduce redundancy and to improve efficiency. It will help in cost reduction and improving customer satisfaction.

4. PST should also implement project management methodologies for project scoping, scheduling and resource assessment to develop clear roadmap and timelines.

5. PST should also define KPIs to identify progress and communicate its own worth to top management

*Names are disguised.

prepared by GSJ.