Issues with novel IT projects

As soon as an IT project has the characteristics of moving into new unexplored fields, the uncertainties increase. Now why is it that these big projects so often fail or simply end in time and cost overrun? One of the reasons could be related to the relationship between learning and ability to change design over time.

With more and more project managers and especially sales people avoiding the waterfall approach; it demands more and more from the developers to make the underlying framework as compatible as possible. This is due to the opposite functions of ability to change the design and the acquired learning through the project. When frameworks like SCRUM is used where things can be changed over time when learning takes place; it become the situation in the graph below. The graph clearly shows the paradox of learning over time and being able to change the project.

What happens is that over time learning takes place and more and more knowledge is available on what the projects is suppose to be like. However, while the project is on, it has to move forward and decisions have to be made and specifications must be “freezed”. The underlying platform of the project must therefore be made in a way that it will be compatible will different kinds of designs and demands later in the process. One way to do this is with the use of the modularity concept. The modularity concept is based on the framework where each component has a standard interface, which enables one to substitute parts when something better is available.

Ron Sanchez, Professor from IMD Lausanne and Copenhagen Business School talks about the benefits of modularity in and interview here: http://www.connected.org/media/modular.html The article is more based on products rather than IT projects, but Ron Sanchez claims that it can be transferred to any type of project.

Since the scope and the WBS (Work Breakdown Structure) must be done in the beginning it is important that it is kept in mind that learning through the project might force the project to be changed. When doing a project with a brand new scope that no one has done before it is therefore important to keep this in mind. Time must be put aside to evaluate the learning, to ensure that learning are not lost while trying to force the initial platform all the way to the end.

This therefore concludes that a rigid Stage-Gate process with out feedback loops will be less attractive compared to a process where learnings are used to optimize the project.

Team learning fosters project success

It is common practice in most companies dealing with projects, to improve the project manager’s skills in trainings and seminars. This leads not only to project managers with very different training experiences, vocabulary and documentation standards. It also ignores the fact, that a project team not only consists of project managers, but of business analysts and maybe contract managers and that the project team can only perform as good as its weakest member.

The solution to this problem is obvious: Take all members of the project responsibility life cycle and train them together in an integrated seminar program. All members benefit from that approach by realizing how they fit in the bigger picture of a project and what challenges and issues arise for other team members. The team will turn away from silo thinking and team efforts become more and more aligned.

The Los Angeles Department of Mental Health (DMH) recognized the above mentioned weaknesses in recent training approaches and built up a new plan for integrated team trainings. Motivation for their research was that a new Mental Health Services Act increased their project workload by 30%, while still being understaffed. Therefore, the DMH mandated ESI International, to work out a training plan that enables them to execute a series of projects more effectively.

ESI International created a training roadmap that combined business analysis training with teaching of standard project management knowledge for entire project teams. Every class was finished with an exam, so that class participance could be ensured. As additional motivation, a formal certificate was handed over for finishing all classes of the training project. Besides that, non-IT people were taught in IT project management, to give them an insight into the other perspective.

In fact, all employees who finished the program were more effective afterwards. This was proven by conducting a big project for countywide integration of medical health information. Despite the understaffing, the project stayed on time and on budget, which is not common for projects at all. In addition, the county CIO office took DMH’s approach into consideration when planning a formal training for all governmental IT project teams. They combined the best aspects of all approaches to a final training plan.

Teamwork training fosters reliance on each other, as well as confidence and morale in the team. Even the manuals from classes serve as reference for issues in everyday business.

It is obviously a huge improvement in team outcome, to use this method of team training. Nevertheless, some specific topics for project managers cannot be covered in team classes. Project human resources trainings for example have to be offered only to employees who have personnel responsibility. Contractors are hard to fit into company internal team trainings and business analysts might need more basic trainings than project managers.

Sources:

Damaré, Bill. "Workplace learning to improve IT project management". Public Manager, Winter2008, Vol. 37 Issue 4, p45-50.
http://proquest.umi.com/pqdlink?did=1642648481&Fmt=7&clientId=6993&RQT=309&VName=PQD

Overview Agile Project Management

In fact, it is one word which illuminates the foundation of agile project management practices and their necessity: speed. Take the advent of new and often disruptive technology that are permeating operations in almost all service providing and product manufacturing industries, or look at the fast-pace business landscape resulted from extremely competitive markets; speed is the constituent of many deriving elements of today’s market, which forces IT managers to decide and act quickly under incomplete information and high uncertainty. As Gary Chin notes it in his book Agile Project Management, “teams need to be light on their feet … they need to be agile!”

Agile project management (known also as iterative life cycle) is defined in environments with high uncertainty and high urgency. Traditional project management approach – waterfall – are not able to cope with rapid and constant change in software projects, and fail to deliver proper functionality under uncertainty, for several reasons:

• Rigid procedures are needed to regulate change.
• Hierarchical organizational structures are means of establishing order.
• Increased control results more static, rigid hierarchies.
• Employees are interchangeable “parts” in the organizational “machine”; it is costly to adapt them to change and prevent negative consequences.
• Problems are solved primarily through task breakdown and allocation.
• Projects and risks are adequately predictable to be managed through complex up-front planning.

Agile technologies such as eXtreme Programming (XP) and SCRUM are meant to reduce the cost of change throughout the software development process by approach the problem iteratively with rather small durations for iterations. Moreover, an agile management approach tends to consider the project manager more as a leading position, and less as a task enforcement and assignment role. Therefore, as developers extend their involvement in the project, they can locally organize their favorite tasks and align them with the general vision of the goal, which is guided and reinforced by PM throughout the project life cycle; this leaves much more space for creativity in agile environments than traditional approach.

On the other hand, chaos can be prevented or controlled by setting general standards and simple rules and light touch with just enough control to foster emergent order. As elaborated in Agile Project Management by CC Pace Systems, complex adaptive systems (CAS) in nature (e.g. flocking of birds, schooling of fish) exhibit similar practice. Among CAS common practices, light touch control stands bold with the implication of applying “just enough” control which ensures that all plans are synchronized with PM’s vision, and are based on functionality to be delivered. Hence, teams will have a level of autonomy to quickly adjust solutions to changing situations on their own, while the desired vision of the project is maintained.

When traditional PM should not and cannot be dismissed, agile PM expands the opportunity of success in projects for which the future is not certain and determined. Traditional PM lacks agility to adapt rapid and inevitable changes; agile tools and methodologies, if aligned with those of traditional PM, can bring about necessary flexibility to IT software development.

Sources

Gary Chin, “Agile Project Management, How to Succeed in the Face of Changing Project Requirements”, 2004CC Pace Systems Inc., “Agile Project Management”, 2008Scott W. Ambler, “Agile Project Planning Tips, http://www.ambysoft.com/essays/agileProjectPlanning.html, Website – Wikipedia, http://en.wikipedia.org/wiki/Agile_management

Project Management and Ethics in IT Sector

Project management and Information technology go hand in hand. However, in the era of technology the overall expectations of clients, executives and customers have increased multifold. In the context of IT, implies reduction in project cost, human resources and time requirements.

In my opinion, the project managers are at the receiving end because they have to perform and deliver within the pre-allocated resources and often rushed deadlines. Frequently managers or other team members have to cut edges to deliver on time and within the approved budget. Or managers expect their team members to work overtime and withdraw vacation time. All this leads to low staff morale, poor product quality, cost overrun or project failure.

In developing countries the situation is even worse. The other day I called my newlywed sister and brother in law both IT professionals in India working for reputed firms. They are working 12-14 hours daily with barely one day off in a week. It is a known fact that in IT sector the final stages of software development are crucial, long working hours are a common scenario especially during the implementation phase.

What struck me most was not their long working hours but their inability to change the circumstances. Project managers will tell them bluntly that everybody else is doing extra hours. They do not have any provision for overtime or flexibility to say no for extra working hours. One has to go with the flow to survive the unorganized private sector in India, primarily catering North American companies. The employees do not have a voice because skilled human resources are in surplus; at least ten people are ready to take over any IT professional, regular working hours do not pay a decent salary and some people take it as an opportunity to shine within an organization.

No doubt this outsourcing business has provided bread and butter to many homes in the developing countries. But we have to be careful as Barbara Ehrenreich once said “Personally, I have nothing against work, particularly when performed, quietly and unobtrusively, by someone else. I just don't happen to think it's an appropriate subject for an "ethic."

The citizens from developed countries need to focus on the ethical issues arising in the developing world because of their IT projects or requirements. The employees should be empowered to receive bare minimum human rights. The onus should be shared including the HR costs by the business owners in developed and the developing countries.

References: Legal working hours and real working hours are different by Nita a renowned blogger.

Analysis of Microsoft Project

Microsoft Project is a project management software program developed and sold by Microsoft. Project was introduced in 1984 for DOS by a vendor for Microsoft and a GUI version was released after Windows was launched, with the latest version being released in 2007. Although Project is a part of the MS Office Suite, it has always been sold separately.

Features
Project is designed to primarily assist PMs in developing plans, assigning resources to tasks, tracking progress, managing budgets and analyzing workloads of different resources. It can be used to create budgets based on work assigned and resource rates. The resource definitions (people, equipment and materials) can be shared among different projects using a shared resource pool. Project Server stores data in a central SQL-based database, allowing users to display and update this data over the Internet. Project Web Access allows authorized users to access a Project Server database across the Internet, and includes timesheets, graphical analysis of resource workloads, and administrative tools.

Pros
Project caters to almost any need of a PM. It works as a task scheduling tool, resource management utility, and a project budget planner. It also integrates extremely well with popular Microsoft Office programs such as Excel and other Microsoft products like SharePoint. Combining Project with Project Server also provides a number of high-powered collaborative features that larger businesses will find extremely beneficial.

Cons
One of the biggest advantages of Project is also its major disadvantage. The numerous features of the tool may be too much for the project management needs of a small organization. Moreover, Project is quite expensive. A single user version Project Professional 2007 retails for around US$999.95 and Project Standard 2007 for US$599.95, but a 60 day trial version is available for download from the Microsoft website.

Competition
Project has dominated the project management tools market for a long time, but it is starting to face competition from open source, online project management tools such as Projjex (www.projjex.com) and Projity (www.projity.com). These tools are becoming popular with smaller organizations and individuals due to the high cost of Project.

References
http://www.brighthub.com/office/project-management/reviews/2516.aspx
http://www.brighthub.com/office/project-management/articles/37156.aspx
http://jsbi.blogspot.com/2008/05/finally-ms-project-and-basecamp-get.html
http://www.microsoft.com/project/en/us/project-professional-2007.aspx
http://office.microsoft.com/en-us/project/FX102464431033.aspx?ofcresset=1

Monitoring the “Energy” of a Project

Mapping and Managing Momentum in IT Projects
R. Ryan Nelson and Karen J. Jansen (University of Virginia)
MIS Quarterly Executive – September 2009

This article looks at the concept of momentum, the shifting of energy, in IT projects and introduces a momentum map as a management tool.

The article defines momentum as the level of energy associated with the collective’s pursuit of a goal-directed initiative. The idea is to map the momentum of each stakeholder or functional group at different points in the project in order to monitor its health and plan the next stages of building or maintaining momentum. Kick-off meetings and reaching milestones are considered positive momentum events which will increase energy levels while staff turnover and techno glitches are negative events, decreasing project momentum.

Retrospectively momentum maps can be used for post-implementation audits or to retell the story of the project since fluctuations can be linked to key events. The idea is that the PM can solicit learnings by trying to identify the reasons for inflection points or momentum swings.

Momentum maps can also be used to communicate with project stakeholders – the convey information about changes in how the project is being perceived by different stakeholder groups and show the overall energy level of the project teams.

The article looks at a study of 51 momentum maps and highlights how projects team found that these maps are valuable for highlighting underlying dynamics and helping to explain how and why events unfolded the way they did.

The study found that proactive management of momentum during implementation lead to improvements in time, cost, product, value, use and learnings. In analyzing the momentum maps from each of the project teams (developers, mangers, users and sponsors) and the study found that in general all the teams have the same perception of momentum at any given time. Most maps showed increasing negative dips as the moved through its lifecycle.

The article claims that as a PM being aware of the events / activities that influence momentum can help you manage the project successful and shorten the implementation.

It states that the top 5 factors contributing to momentum changes are:
Increase

• Perceived progress towards the goal
  
• Launch events
• Communications
• Change in project leadership
• Sponsor encouragement

Decrease

• Slow progress / missed deadlines
• Resource constraints
• Technical problems
• Requirements issues
• Ineffective/changing project leadership

Momentum maps are a PM tool used that can be used to monitor and related the energy levels of project teams and stakeholders to specific events.

Reference: http://misqe.org/ojs2/index.php/misqe/article/view/237

Using energy to manage projects – it’s an interesting concept.

ITPM Meet SM - You guys look great together.

The landscape is changing. The groundswell of Social Media (SM) is upon us and it’s changing the playing field in almost every industry, the world of IT Project Management (ITPM) is not exempt. Now IT Project Manager’s have a real-time gage on how well their projects are performing. This is certainly not in all cases, but when we consider the recent failure of the Vancouver 2010 Olympic ticketing site there is a clear indication in the social space of when things began to go sideways.

Background

In January 2008 Tickets.com won the contract to manage the ticket sales for the 2010 Olympics in Vancouver. "Tickets.com has an impressive track record and extensive Olympic ticketing experience, having managed the successful ticketing programs for the Atlanta 1996 Summer Games, and the Salt Lake 2002 Winter Games. Tickets.com's Olympic ticketing engine was also the backbone for ticket sales and distribution for the Sydney 2000 Summer Games and the Torino 2006 Winter Games." ¹

Tickets.com has a great deal of experience in the management of ticket sales. The only thing that I could see as being different is the use of a Virtual Waiting Room (VWR). After performing a few searches I’ve found that the VWR is actually quite a common tool - though it is certainly on loved by users. Dubbed the “worst kind of waiting room” by most bloggers - it’s a holding patter that offers little more consolation that the elevator music of years gone by.

This quote from Tickets.com’s own site: “The virtual waiting room helps manage the incredible amount of traffic,” said Carl Rice, senior director, information systems and special projects, Chicago Cubs.² Suggests that their solution is a great answer to the problem of high online ticket volume. One might suggest that this tool was not the problem at all. - But I digress

Using SM in ITPM

This is really a focus on the SM tools available to track issues with the launch of your project. As the Ticketing system began to fail people started to share their frustration. If you were to search Twitter for “Olympic Tickets”³ as I did on the 8th of November you will quickly find masses of people expressing their frustration with the site in question. Some of the quotes found were:”Glad I don't work in IT for Olympic ticket sales.”, “If U2 can serve video of a concert to the world in real time, Vanoc should be able to handle Olympic tickets.”, “Has anyone been successful getting Olympic tickets this morning?”, “Olympic tickets done for the day, maybe will try again tomorrow. Major FAIL”

Fortunately for VANOC, they were paying attention to these comments. At 10:12 they said “Hang in there folks, lots of traffic on the tix site today.” At 10:28 “Folks, we're aware of the issue on the tix site and hope to have that solved shortly. Hang in there - its a very popular site today.”, then a few minutes later at 10:31 “Fans - making some progress on the tix site. Its getting better. Hang in there.” Unfortunately the next time there was communication was at 1:18 when they said “Tix postponed to Nov 14 http://bit.ly/1mTfds” With this link to a more detailed message entitled: Vancouver 2010 Phase 3 Ticket Sales postponed to November 14.

If you are going to listen and talk back - be sure you keep the conversation going even if you don’t have any good news. It’s ok to say “We still don’t know what’s wrong - but we’re working on it.”

VANOC was able to keep users informed while they worked on a solution. Could they have done better? Yes. Three hours between postings in a real time space like Twitter is far too long particularly when people are wasting their time sitting in your VWR - was there even any music?

1. http://provenue.tickets.com/US/about_us/press/PR012408.shtml
2. http://provenue.tickets.com/US/about_us/case_studies/cs_06.shtml
3. http://twitter.com/#search?q=Olympic%20Tickets

The Failure of Virtual Case File and the FBI

Background

The FBI first sought to embrace technology in the 1980s during the onset of computer availability and hoped to have a paperless office where agents could quickly pull up case files, information, and photographs at the comfort of their desks without having to sift and sort through numerous paper files. The infrastructure in that time was limited to text based search engines and there were no provisions for photo storage or the ability to scan written reports. As a result, the FBI found its agents decided not to rely on the existing technology and were reverting back to paper. After the attacks on September 11, 2001, the FBI was placed under scrutiny for being ineffective and inefficient in its operations due to the time it would take to share information with other law enforcement agencies, locate reports, and transmit them from one location to another (usually done via fax or by mailed CDs). To combat this, the FBI developed a plan known as Trilogy, which aimed for three primary goals: A new computer network, personal computers for most agents, and an online criminal database that would be titled Virtual Case File (VCF). An external contractor by the name of Science Applications International Corp. (SAIC) was contracted in June 2001 to begin the project with an estimated schedule of three years for completion and a first year budget of $14 million. The project continued until early 2005 (7 months over schedule), at which time the project scope had expanded by 80% with costs of $170 million and was riddled with issues. Ultimately, in early 2005, the project was cancelled but not after escalation and persistence on the part of the FBI.

The Problems and Failure of VCF

The FBI wanted SAIC to create the database from scratch instead of using off-the shelf Oracle programs that could have been customized. A study by the National Research Council (NRC) after the planned 3-year period in late 2004 was conducted to gauge the success of the program, and while the first two goals had been achieved (personal computers for most agents and the creation of a new network), VCF was found to be problematic and incomplete. The project plan was incomplete and there were no monitoring controls regarding finances or the schedule. The FBI threw quality out the window by wanting to bypass testing and release the product upon its ready date. However, VCF failed the most basic functionality tests under the NRC and had not included network management, security, and storage systems, or basic sorting capabilities. The study also found that most of the FBI's skilled managers had left for the private sector and there were little to no individuals who had the IT experience or knowledge to interact effectively with contractors to achieve what was needed. The definition and scope of operations and processes were ultimately entrusted to SAIC who were outsiders.

In an attempt to salvage the project, the FBI immediately hired a federally funded R&D firm (Aerospace Corp.) costing $2 million to conduct an assessment of the project who concluded that the project needed to be scrapped and shut down due to the severity of the software issues. Upon investigation by Congress, there was a lack of financial controls and safeguards on the part of the FBI, enabling SAIC to continue to develop a program which was lacklustre and failed to meet objectives. 200 programmers from SAIC were used on the project when only a dozen were required and SAIC was not being properly monitored by the FBI. They felt as long as money was being funnelled to them by the government on the project, they did not need to be responsible for the effectiveness or viability of the program they were building and fired staff who expressed concerns over the direction of the program. Further, the FBI took a trial by error approach to the project without truly understanding their end goal and without setting benchmarks for evaluating the progress of the project and took a nearly hands off approach by entrusting SAIC entirely. SAIC claimed the FBI were indecisive in what they wanted and there had been 19 government personnel changes over the project tenure which brought on scope creep and the focus of the project in a state of flux, in addition to a clear lack of leadership. A further $17 million was then spent by the FBI to perform more rigorous testing to try to salvage the project once more, which was another missed opportunity to cancel the project. It was only in early 2005 that the decision was made by Congress to terminate the project.

Source: Eggen, Dan; Witte, Griff. 'The FBI Upgrade that wasn't'. August 8, 2006. Website: http://www.washingtonpost.com/wp-dyn/content/article/2006/08/17/AR2006081701485.html (accessed on November 7, 2009).