IT Project Management

Frequently used words (via Wordle.net) in the recent posts

2011-12-29T14:03:00.000-08:00

How to succeed in projects

2011-11-14T11:29:00.001-08:00

“If builders built buildings the way programmers writeprograms, then the first woodpecker to come along would destroy civilization”

– GeraldM. Weinberg, Weinberg's Second Law

There maybe some truth to that butif we look at things from a 2000 ft cruise altitude, we may infer differently. In1628, the grand warship Vasa launchedfor her maiden voyage. It started as a ceremonial trot around the Stockholmharbor but ended up in a disaster within ten minutes. The Vasa sank, taking many of thoseaboard with her. Loss of lives, money, reputation, and availability for warwere a few of the consequences. Can we blame the shipbuilders as we blame theprogrammers – or is there a bigger problem, perhaps in the process used tobuild Vasa or create softwareprograms or in project management method.

It is easy to point fingers but tofind the root cause of a failure and use the lessons for the future is theright thing to do. Often, the difference between success and failure isspotting critical early warning signs that a project is in trouble. Rich Cookwrote an article for CIO.com in which he described IT project failures as afish left too long in the refrigerator, the failure becomes all too obvious. Oncethe fish starts to stink, the clean up of the fridge is done using baking soda.Only about 1/3 of the all projects end up being successful. So how do youconvert project failures into project success – spot the stinky fish early. Howdo you do that? – add probes or sensors in your refrigerator that would triggeran alarm before the fish goes bad. Let us further examine what those sensorscan be that will help us detect problems on a project. A lot of these are hardto measure objectively as some of these detection patterns come withexperience.

Transparent Communication

One of the keys to detectingproblems on a project is to have open communication. Managers don't have towait for a status report meeting to find something is hung up. One key wayto facilitate transparent communication is for managers to build trust with theproject team members. If a project manager feels that the communication is nottransparent, he or she should look at building trust and also keep track of thegrapevine messages. Both inter-communications between management with the teamand intra-communication between team members need to be healthy. It is themanager’s job to effectively manage both and resolve conflicts before theyescalate. "Everyone is allergic to bad news." As a result, it's alltoo easy to develop a culture where bad news is slow to percolate upward – whichdeprives management of vital, if unpleasant, information. An environment wherebad news is accepted will help build that trust for employees to betransparent. The earlier the bad news is received, the easier and less costlyit is to fix the problem.

Project Management Methodologies

Project management methodologiesused to run a project could also determine how quickly problems can be detected.Proponents of iterative development (agile project management) focuses onbreaking projects into small chunks and delivering pieces of it fast for userfeedback – this help to correct the course of the project as there are severalmilestones and the risky issues are handled first. On the other hand, waterfallmodel where the entire project proceeds step by step from analysis to finaldelivery can be hiding problems till no recovery is possible. More themilestones, better the tracking.

Lack of Commitment

Detecting lack of commitment orinterest from project members can be another sign, which could lead to failure.One way to prevent that is to allow members to take ownership of the work theyare doing. Also, the members should understand the goal and vision of theproject and should be motivated by the outcome with tied incentives.Inherently, majority of software developers are introverts. Therefore, having apositive energy in the work environment helps. They are also creators soproviding them flexibility in terms of work schedule can help them motivate. EASports is big on providing their employees with flexible work environment.Although working on a video game can be motivating enough, working to meetstrict timelines can be de-motivating. So offering flexibility and additionalon-campus services (e.g. gym, dry cleaning, car wash, mani-pedi, etc) helps toget them committed.

Project Management Tools

Moving on to more objectivemeasures, there are tools, which can tell managers of the heartbeat of theproject. Managers can use dashboard tools that provide visibility into aproject at the click of a mouse. Tools like TargetProcess can help keep trackof progress. It works similar to the tracking tools car dealers use when youtake your car for servicing. The tool keeps track of every detail of the workthat is supposed to done. It tracks who is working on it and the progress fromone stage to another. One word of caution is that these tracking tools are asgood as how well the employees input their progress. Therefore, propergovernance is needed to maximize the use of these tools.

A way to hide problems on a projectis for employees to work lots of overtime. In the Giga Safe case, the employeeswere working overtime with no proper strategy and the management was trying tomeet the deadlines by making the teamwork work hard and not smart.

Another sign of a troubled projectis when an enormous amount of resources are diverted to one project. From mypersonal experience, I have seen it happen a few times where several new teammembers were assigned to a “troubled” project. Most of the time this resultedin delays with old members training new ones and the quality of the end productsuffered.

Schedule slips can trigger alertsthat the project is in trouble. If there are too many reported software bugsthat haven’t been fixed, may indicate a quality issue. Last but not least,scope creep or scope relaxation can also be indicators that the project isrunning into trouble.

All these project attributes can betracked via a project management tool with active updates to management fromthe reporters. These project attributes are similar to the smelly fish and thetools are our sensors to detect the smell and notify us of a rotting fish – inthis case a troubled project.

http://www.cio.com/article/print/124309

http://www.targetprocess.com/

prepared by Deepak

21 Ways to Excel at Project Management

2011-11-14T10:21:00.001-08:00

Project Smart provides a list of practices that would make project managers excel. This is the web version of their popular ebook in the same title. After explaining 21 factors that affect the performance of the PM, they put together a checklist that helps PMs to gauge where you are at.

It takes two to tango

2011-11-14T09:57:00.001-08:00

In a recent blog post by Michael O'Brochta and Curt Finch at Project Smart, they refer the expression in the title to describe the relationship between a project management office (PMO) and an executive. As they elegantly put:

At the end of the day, success for either of them is dependent on the other. Executives depend on the work accomplished by project management offices for their own success, just as project management offices depend on executives for their success.

O'Brochta and Finch did a great job in discussing how healthy relationship between PMO and executives should be. Good that they are going to describe specific key performance indicators that a newly-established PMO can use to measure itself to ensure alignment with the needs of the organisation in their follow-up piece.

Three common mistakes that flood IT Projects

2011-11-10T23:15:00.000-08:00

Three common mistakes that flood IT Projects

I have been involved with IT for several years now. Since my high school years I've seen many IT initiatives fail miserably (i.e. disastrous implementation, horrible IT solutions, incomplete initiatives, etc.) and I've seen others be tremendous successes.

I recently came up with a blog posting by Ty Kiisel about common mistakes that plague IT projects. Seeing in retrospective, in one way or another, I can identify with those mistakes he mentions in the blog.

For example, he talks about the project manager setting up unrealistic deadlines for the team. The author suggests that while some projects require a hard deadline, most of them don’t. In my experience that holds true, or at least not you shouldn’t set up unrealistic deadlines especially when you are not expected to set them. I remember a time when one of our clients wanted to implement a new 3D scanning system in his manufacturing plant as part of a new quality management control system. The system consisted in a combination of cameras, sensors and software that took several pictures of a certain object and compared them against a previously defined “quality” product. The problem with this system is that it was the first time anybody in the team tried to “cluster” the cameras to shoot at the same time and tried to automate the camera’s functions via programming language. The client was very interested in the project because it would increase the speed of the quality control system without hiring more people. During the negotiations with the client, my team leader offered the finalized product into what we thought would be a very tight schedule if we knew the technology. When we found out what we were faced against, we discovered the deadline was totally unrealistic. Fortunately, the client was nice enough to accept a delay of over 4 times the expected delivery time. Lesson: never commit to a deadline (specially to an unrealistic one) just to impress people at the beginning, at the end you will impress them in the totally opposite way.

Kiisel also talks about risk not being managed and how ignoring it does not make it go away. I worked with a partner for a significant academic project as part of our thesis. We were building a vehicle traffic simulator in various computers at university. We had heard how a recent electric failure in one of the adjacent computer labs of the building had fried two of the research servers used in a thesis project for other group and how they lost nearly two years of research due to data damage. We were aware of the risk and we thought we should take precautionary measures in order to avoid data loss. We made backups of our data the next week and we forgot about the data loss case as the time went by. Nearly six months later, the same problem happened again but this time the fried computer was our server. If it hadn’t been for a backup made a week earlier by the recent automated backup system installed by the Research Department, we would have lost a tremendous amount of our time and data critical to our final project.

Finally, Kiisel also talks about the mistake of stakeholders not involved in the project. I found this several times in IT projects of third parties. For example, I remember how a supposedly high-tech emergency communication system installed in the school where I worked failed miserably. The US Department of State, through the US Embassy in my country, gave a substantial grant for the implementation of an emergency communication system installed in all school classrooms. The sponsor unilaterally decided to outsource the project to an external company that did the installation over a period of two months working during the weekends. The company never interviewed any of the stakeholders (faculty members, support staff, students, etc.) to gain insights about our needs, about stakeholders’ tech proficiency, among other factors. The result was an installed high-tech system that was so complicated to use that nobody could actually operate. The old system (walk and notify to the nearest secretary –even if she was in a different building-) was brought back and the new system was abandoned and remained installed as a symbol of failure. Personally, in this case I think there was more than just bad project management as I suspect the sponsor had some dubious interests in the company and technology used. This feeling became stronger when he was fired soon after the failed implementation of the project.

Watson

2011-11-10T22:40:00.000-08:00

We have discussed some project failures so far in our course, which have been very telling, and even quite entertaining at times. I would like to share a brief chronicle of a highly successful IT project I have read about recently, IBM Watson.

Watson is a compute cluster built by the firm's DeepQA division. DeepQA's mandate is to perform research in the realm of artificial intelligence (AI) centring around human-like “open-domain” question answering. Open domain question answering is basically the phenomenon of a machine answering questions expressed in natural human language.

The 90 node, 2880 core, 80 teraFLOP Watson is among IBM's most impressive projects to date and in February, 2011, it beat the two top Jeopardy contestants of all time in a two game match demonstrating its capabilities.

This amazing feat was made possible, not only by brilliant engineers, architects, and powerful hardware, but highly organized and effective project managers as well. One of those project managers, Jim De Piante, sourced talent for practise competition against the supercomputer. Other key sub-projects included hardware delivery and staging, sample question development. Meanwhile, several other technical and non-technical project managers coordinated the efforts of at least nine other groups working in linguistics, systems, software development, game strategy (for playing Jeopardy), data linking, search, and more. Additionally, project managers had to coordinate all these complex sub-projects in order to complete the entire package that is Watson.

The budget was over three million dollars and the project was completed in approximately two years.

In order to ensure the project was completed on time, on specification, and on budget, project managers had to have a solid understanding of the ambitious project goals, resource constraints, software development, supercomputer hardware, human language, artificial intelligence, and working with a multicultural distributed team in four countries on a project some thought was impossible. It was an impressive feat indeed.

Sources:

http://www-03.ibm.com/innovation/us/watson/research-team/

http://en.wikipedia.org/wiki/Watson_(computer )

http://www-03.ibm.com/innovation/us/watson/

http://www-03.ibm.com/innovation/us/watson/building-watson/index.html

http://www.research.ibm.com/deepqa/deepqa.shtml

The importance of functional gap analysis to project success: A personal experience

2011-11-10T16:19:00.001-08:00

I was recently involved in the preliminary stages of a IT project ,at large organization, that aimed to replace the central information sharing and document archiving system. The current system was a 10 plus year old mishmash of interdependent modules that were developed in house to meet the needs and demands of various stakeholders. The system no doubt needed to be replaced; the challenging question was what new system would provided the same level of functionality and integration with current business processes.

Despite the obvious challenge in finding an appropriate replacement system, upper management, due to financial pressures and politics, committed themselves to an off the shelf solution designed by an American vendor without conducting a functional gap analysis in co-ordination with the major stakeholder. The scope of the system replacement project was therefore limited to; getting major stakeholders to support the proposed change, working with the selected vendor to implement the system and pre-launch training.

The omitted functional gap analysis was a sure recipe for failure. The project planning stage, of which i was part, uncovered several intractable challenges the implementation project will be facing due to the omitted functional gap analysis. The standard answer to each new uncovered challenge quickly became " well we are already committed to the new system". However, as the project planning progressed and more challenges were uncovered an unspoken consensus slowly emerged; the planned implementation will run into significant problems and the selected system will most likely not meet the needs and demands of its users. In my estimation, this state of affairs were a direct consequence of the failure to conduct a proper functional gap analysis before selecting the replacement system.

I suspect that the situation I encountered is not uncommon. I imagine that economic pressures or the lure of the latest IT tool or fad, for example cloud computing, frequently motivates managers to commit similar errors in judgement that ultimately jeopardizes project success.

In the interest of exploring my suspicion further, I will be happy to hear from other members of the class who had had similar project experience.

2011-11-10T16:17:00.000-08:00

The top 10 Global Project Management Trends for 2011.

According to J. LeRoy Ward, PMP, PgMP, Executive Vice President, ESI.

1) Leadership - Leadership skills will be the PM’s critical success factor. In current business environment leadership skills become more and more important

2) No Industry Will Be Spared from the War for PM Talent. Especially with growing number of projects going overseas, there is a growing need for experiences PMs.

3) Agile Project Management Not As Popular As Before - More organizations will realize that Agile does not suite all organizations

4) Competency Models Will Be Core to Managing Professional Development and Promotions for PMs - Hiring managers will be more sophisticated on selecting PMs. They will base their selections on comprehensive competency models.

5) Experiential Learning Will Be More the Norm than the Exception – Learning at work become more important. PM courses having hard time to keep up with the changes.

6) Informal Learning for PMs Will Gain Momentum – More learning will be acquired by using social learning technologies and approaches, such as wikis, blogs, videos, podcasts and other methods of communication.

7) Project Sponsorship Will Become an Area of Focus in South Asia - especially in India and Bangladesh, as organizations try to accelerate their structured approach to project management.

8) Outsourcing Will Remain a Risky Business – It means that PMs will have to focus more on the risk management and recognize the value of best practices in contract management.

9) PMs Will have to collaborate more with Change Management Experts – In a constantly changing environment PMs will drive the change, but they will need a reliable assistance.

10) The PMP® will continue to be the most popular project management credential in the world, but Will No Longer Be Enough – Companies worldwide will continue to support PMP®, but will value the proven experience and demonstrated competency beyond the certification itself.

2011-11-10T14:52:00.000-08:00

The failure of the License Application Mitigation Project (LAMP):

Background:

The License Application Mitigation Project (LAMP) is one of the most famous IT project failures. This project was started in 1990 by the state of Washington. Its goal was to automate the state's vehicle registration and license renewal processes. Initially, the project was supposed to cost $16 million over five years. However, in 1992, the projected costs had climbed to $41.8 million, $51 million in 1993. It was lats estimated at $67,5 million in 1997. Finally, it became clear that the costs of installing the system were out of control. And, even if the project were completed, it would continue to be a huge and costly waste of money.

LAMP was turned off in 1997 after legislators calculated that this new system would cost six times as much to run every year as the system it was replacing.

It was estimated that nearly $40 million had been wasted in this project.

What reasons could lead to this failure?

Problems:

The project’s failure stems from three main problems:

1) Management of the scope:

LAMP’s undertaking and expectations were very high. This was a very big concept which had very few intermediary deliverables. According to George Lindamood, the director of the state's IS department from 1993, "the project should have been broken down into smaller, measurable chunks, rather than spread out over several years.” Moreover, the requirements were constantly changed during the course of the project. For instance, after Lindamood left, legislators passed new licensing and registration laws that altered the project scope and caused further delays.

2) Split of the project between in-house developers and a private industry contractor:

By design, LAMP tasks were inexplicably divided between in-house developers and an external company. This led to communication problems and poor coordination. This is one of the reasons why LAMP faced so many delays.

3) Bad project management:

The chief issue about management was administrative meddling. From authorization to purchasing and quality assurance, LAMP was overseen by a mix of elected officials and political appointees. Not only these officials and politicians were not technically knowledgeable about the project, but LAMP was not a priority in their agenda. Experienced personnel should have been hired from private industry and empowered upfront, as opposed to putting political appointees in charge during the project.

The other management issue was that the organization didn’t want to hear that the project was a failure. The signs of failure for this project were evident from the first two years. Yet, no action or initiatives were taken to prevent this failure from happening. Project management should have identified and taken the following actions:

-Recognize and admit the symptoms of failures.

-Accurately identify what is going wrong in the project.

-Select suitable means of handling the situation, be it cancelling the project before costs become so huge.

What we can learn from this failure:

The chief lesson to learn from LAMP failure is that when a project is obviously doomed to failure, get out sooner rather than later!

Sources:

http://news.idg.no/cw/art.cfm?id=E38554CD-17A4-0F78-3158BDA5AC9294E6

http://www.inf.ed.ac.uk/teaching/courses/seoc2/2004_2005/slides/failures.pdf

http://www.cio.com.au/article/108289/managing_--_hell_back_/

http://infocommodity.blogspot.com/

Lucie BIENVENU

Project Management Crisis? Hurry, But Do Nothing

2011-11-10T12:41:00.000-08:00

Scope: Clearly defined scope and risk avoidance mechanism is also very important. Project scope approval by client and sponsor is required and any change in the scope should be taken as a change request.

The first part of the post is a replication of a post at http://PMToolsThatWork.com/project-management-crisis-hurry-but-do-nothing/ . I will then offer my analysis in the second part.

Project Management Crisis? Hurry, But Do Nothing

[The original is at http://PMToolsThatWork.com/project-management-crisis-hurry-but-do-nothing/]

We had a crisis. Another project had an emergency so we were losing a significant portion of our engineering staff to go work on that project. We had to act now!

We were told to replan our project and to present a new project management tool schedule. No problem, we already had an alternate schedule ready. It was the schedule that had been rejected previously for the shorter one that was accepted. We adopted the previously rejected schedule and went on to deliver our product on time. One of our biggest customers told us that it was the first time in their memory that we had delivered a new product in the time frame we had promised it.

It was really fortunate we had a well developed schedule all ready to go. Actually, it was not fortunate, it was routine. Well, the part that was routine was that just about every project eventually had to respond to an emergency in another project trying to finish that caused newer projects to lose staff. The fortunate part was that we had tried to propose a schedule – one based upon objective data from just completed projects – but that schedule was rejected as too long. The humorous part was when we said we would use the previously rejected schedule, we also said it was ready to go and did not need to be updated. How could that be as we were months into the project? It was possible because that schedule already took into account the inevitable loss of staffing because it was based upon past actual project performance. (For more on performance based schedules see Get The Project Management Schedule Right!)

If we had used the initially rejected schedule then when the crisis occurred, and we lost staff, we would not have had a crisis. We could have just stayed on the same schedule and pressed on. Actually, we didn’t have a true crisis in any event. Since we didn’t truly need to replan, just use what was essentially the same schedule with adjusted milestones, there was little or no impact to any team. We just continued on course with the staff we had remaining.

The one big difference was that our project never had a crisis that then pulled staffing from the projects coming after ours. That probably helped explain why these later projects went on to receive recognition and awards for “flawless launches.” Prior to this, we never had any project anyone would have call a flawless product launch.

Objective and performance based planning can take the sting out of our typical crisis. When faced with an emergency we should be hearing ourselves say “no problem, we anticipated this possibility and have it covered.” This may ultimately help other projects to succeed as well.

MY Experience:

I have worked on projects that were delivered on time and also on projected that were not delivered on time or on budget. This has always been in my mind why some projects manage to meet the schedule while others don’t. This article made me to think and I came out with my own analysis. Some things that can create difference are

1) Planning & scheduling: The projects on which I have worked and which failed to meet the deadlines, were not because the team was not motivated or the requirements kept on changing but because the time required to complete the project (schedule) was flawed. The project estimates were given by a project lead who was working on another project and will not be working on this project. So the incentive to come up with the exact estimates was missing. So, who is estimating the project is very important. It is also important to involve the developers and testers in this process.
2) Communication: The client had no idea what was going on in the project and if there was any problem. The project managers were reluctant to talk to the client and explain the problems that the team was facing and when the client knew about it, it was too late. So communication is very important.
3) Planning the resources require: It is also very important to estimate the resources and skillset that are required to get the work done. In most of the projects, the main resources are moved to other new projects once the major functionalities are implemented. This means new resources getting added to the project, which leads to chaos.

Portfolio Project Management(PPM)

2011-11-10T00:06:00.000-08:00

What is PPM?

PPM is a strategy that allows organizations to align their IT and application development projects, resources, and initiatives to corporate business objectives by developing and monitoring measures that treat IT assets as financial assets -- and to run as a project-oriented business. PPM enables integrated management of pipeline, scope, time, resource, skills, cost, procurement, communication, reporting and forecasting, and risk management functions.

In essence, PPM allows us to manage a portfolio of projects much as you would manage a portfolio of diverse investments, such as stocks, bonds, real estate, and so forth. By maintaining a balanced portfolio, you can reduce the risks of individual projects and produce an overall higher rate of return. PPM allows executives and managers to proactively monitor their project portfolios for alignment with business objectives and planned costs and schedules. It also allows them to identify project risks and quickly address them.

Business drivers for PPM

Why do businesses need a PPM strategy? Let's look at some of the strongest reasons:

Limited IT budgets and resources. Most organizations need to improve the way they use their existing resources in order to maximize productivity. This applies to both people and tools.
Need for better IT governance (and data for compliance with Sarbanes Oxley Act ). Many IT organizations lack a consistent, accountable body for decision making. PPM provides a decision-making framework that helps ensure IT decisions are aligned with the overall business strategy; IT participates in setting business goals and directions, establishing standards, and prioritizing investments.
Need to improve project success rate. According to the latest Standish Group survey, executive support and clear business objectives are among the top ten success factors for application development projects. PPM includes approaches for achieving both of these requirements.

Table 1: Challenges for IT management roles

Key benefits of PPM

Closer alignment of IT with business: With an easily digestible, holistic view of their entire project portfolio, executives and managers can more readily understand where IT dollars are being spent and which projects continue to be worthwhile.
Better IT governance: PPM helps managers monitor project progress in real time and provides detailed data to help satisfy Sarbanes Oxley Act compliance specifications.
Cost reductions and productivity increases: PPM helps managers identify redundancies and allocate resources appropriately; it enables them to make better IT staffing and outsourcing decisions, and to spot opportunities for asset reuse.
Business-based decision making: By viewing projects as they would view components of an investment portfolio, managers can make decisions based not only on projected costs, but also on anticipated risks and returns in relation to other projects/initiatives. This leads to improvements in customer service and greater client loyalty.
More predictable project outcomes: A PPM strategy bridges the gap between business managers and the practitioners who deliver the projects; it ensures consistent processes across projects and helps managers assess project status in real-time, predict project outcomes, and identify inter-project dependencies.

Aspects of IT management

As Table 2 shows, the PPM strategy addresses four main aspects of IT management associated with specific activities and functions. The table also details automated support for these activities and functions.
Table 2: The PPM solution framework

Govern

Governance relates to the most important questions for software development and IT managers: "Are we working on the right things, and are we building the right system?" If their teams don't get this right, nothing else matters. A project might be successful from a schedule, budget, or scope perspective, but if it fails to meet business objectives, it fails overall. Efforts to align business and IT objectives are often thwarted by governance issues, such as:

Project teams use different vocabularies.
Team members do not understand the business objectives.
Projects are not prioritized by ROI potential.
Software requirements are not traceable to business objectives.

To address these common causes of failure, a PPM strategy provides support for governance, including:

Method management: A consistent, repeatable process, providing the means for establishing a common vocabulary, instituting a framework for assessing project health, and prioritizing initiatives.
Idea/innovation management: Support for considering IT project requests in relation to other prospective and current projects (project pipeline management).
Portfolio management: Ways to align and prioritize proposed initiatives and projects.

Plan

Functionality that enables planning under a PPM strategy includes:

Program management: A holistic view of multiple projects and their inter-dependencies.
Project management: Support for planning and tracking schedules, establishing milestones and assigning tasks for individual projects, identifying project dependencies, completing Gantt charts and other reporting artifacts.
Resource management: Ways to plan, balance, and schedule resources for IT initiatives.
Time management: Means to allocate, track, and compare time spent on project activities.
Financial management: Help with establishing and managing IT budgets; means for capturing expenses and obtaining approvals.

Build

To ensure that developers build systems correctly, a PPM strategy includes functionality for:

Business process modeling: Support for managers to discover, document, and specify current business processes with metrics, and specify new goals and requirements.
Requirements analysis: Means to analyze financials and prioritize projects according to potential business value, define and prioritize requirements, identify/prepare existing assets for reuse.
Design and construction: Functionality for rapid integration and/or application development, visual construction and programmatic code generation, unit testing and debugging.
Testing and deployment: Support for functional and load testing, and for managing testing requirements.
Change management: Configuration management and change management support to deploy and monitor the solution.

Operate

To verify a system's effectiveness, a PPM approach includes functionality for:

Maintenance and productivity monitoring: Support for testing and measuring system performance.
Business metrics collection: Means for collecting and analyzing post-deployment business results. PPM also helps you track metrics for component reuse.
Setup and monitoring of Service Level Agreements (SLA): Setup for specific IT service levels and metrics collection for response time, service availability, and other parameters.

References:

"How to Run IT Like a Business." CIO Magazine, May 1, 2004. http://www.cio.com/archive/050104/howto.html

"At Your Service," eweek, March 1, 2004. http://www.eweek.com/article2/0,1759,1542787,00.asp

"The Best Best Practices: CIO Research Reveals the Basic Building Blocks of IT as a Business." CIO Magazine, May 1, 2004.http://www.cio.com/archive/050104/best.html

The Blending of Traditional and Agile Project Management

2011-11-09T20:54:00.000-08:00

Traditional project management involves very disciplined and deliberate planning and control methods. With this approach, distinct project life cycle phases are easily recognizable. Tasks are completed one after another in an orderly sequence, requiring a significant part of the project to be planned up front. For example, in a construction project, the team needs to determine requirements, design and plan for the entire building, and not just incremental components, in order to understand the full scope of the effort.

Traditional project management assumes that events affecting the project are predictable and that tools and activities are well understood. In addition, with traditional project management, once a phase is complete, it is assumed that it will not be revisited. The strengths of this approach are that it lays out the steps for development and stresses the importance of requirements. The limitations are that projects rarely follow the sequential flow, and clients usually find it difficult to completely state all requirements early in the project. This model is often viewed as a waterfall.

Today, business processes are more complex, interconnected, interdependent and interrelated than ever before. Additionally, they reject traditional organizational structures in order to create complex communities comprised of alliances with strategic suppliers, outsourcing vendors, networks of customers and partnerships with key political groups, regulatory entities, and even competitors. Through these alliances, organizations are able to address the pressures of unprecedented change, global competition, time-to-market compression, rapidly changing technologies and increasing complexity at every turn. Because of this multifaceted nature of businesses, projects that implement new business systems are also more complex.

However, huge cost and schedule overruns have been commonplace in the past. Looking at the numbers, the past project performance record is troubling:
􀀁 $80 -145 billion per year is spent on failed and cancelled projects (The Standish Group
International, Inc.)
􀀁 25% - 40% of all spending on projects is wasted as a result of re-work (Carnegie Mellon)
􀀁 50% are rolled back out of production (Gartner)
􀀁 40% of problems is found by end users.

The Agile Project Management Environment
Unlike traditional project management, which emerged from the construction, engineering and defense industries and dates back to the 1950s, APM was born in the twenty first century. In 2001, prominent software developers from both IT and software engineering domains, convened to arrived at a consensus on how the software development industry could produce better results. This meeting produced the Manifesto for Agile Software Development, which states that the “highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
APM development is conducted collaboratively, with a small co-located team. There is minimal documentation as the team relies almost exclusively on informal internal communication. Again, this differs from the traditional approach where a considerable amount of time is invested in planning and a significant amount of requirements documentation is produced.
Agile Management Components
There are several key elements that provide the basis for APM. It is important to note that these techniques can also be used in traditional software development methods to improve project performance. They are:
- Visual control - This is a “cards-on-the-wall” method of planning to assist a team in organizing the work of the project.
- Co-located high-performing teams. In Agile development, all the key team members are co-located, including the customer/end-user, preferably in a work room. This approach greatly increases the quality of coordination and communication.
- Test-driven development. In cases when the customer is having a difficult time articulating requirements, agile teams often use test-driven development. Using the same successful Agile project team mentioned above as an example, the test cases were often developed first, and then the team backed into the requirement.
- Adaptive control. Everyone on the team is constantly adapting, which may make some team members nervous, especially those that crave structure. Because of this dynamic environment, the project manager needs to be seen as a leader, not a taskmaster.
- Collaborative development. APM relies on collaboration among all team members to deliver the results, capture candid feedback and implement learning’s on the next iteration of the solution. This is one of the strengths of APM - constant feedback and improvement.
- Feature-driven development. This practice greatly reduces complexity, because it allows the team to focus on one feature and only one feature at a time. For example, one team is working on Feature #4 and that’s the team’s only focus. They don’t concern themselves about Features #1-3.
- Leadership and collaboration rather than command and control. “The principles of APM are timeless. If you look at APM, it links much more closely to leadership. It addresses a lot of the steps that facilitate leadership much more than traditional management.
- Move from C (cost) to R (revenue) focus. Features are prioritized based on value, such as increased revenue or market share. It’s the business analyst’s role to ensure the Agile project team is not investing too much into the development of the new solution.
- Lessons learned. After each cycle, the team holds a lessons learned session to determine what they can do better on the next iteration. As the team learns, it adapts how the members are working together to continuously improve team performance.

Conclusion

“The traditional project management approach,” Augustine reports, “is a linear approach where you try to get it all done at one time. You do a lot of very detailed planning at once upfront and then deliver it in what’s known as the ‘Big Bang’. That industrial age thinking has spilled over from software development to other projects as well.” This is the heart of the difference between Agile and traditional project management. The ‘Big Bang’ now comes from the greater flexibility and collaboration APM provides. “Just enough” planning is done up-front. As each increment of the system is built, the team gathers input and learns from customer feedback.

“At its heart, project management, whether you are doing traditional or Agile has very similar principles. It’s about doing a good job for the customer. It’s about leading a team. It’s about delivering measurable business results,” says Augustine. Many of these principles or practices can be implemented into most team-structured environments.
Incorporating Agile management techniques into projects fosters a focus on the benefits of each feature. In traditional project management, the teams strive to finish the project on time and under budget and often lose sight of the overall benefits the entire effort is intended to bring the organization. It’s important to remember the strategy the project is expected to advance as well as the total cost of ownership and not just the project costs.

Published in PM World Today - May 2007 (Vol. IX, Issue V)
By Kathleen B. Hass, PMP,
Project Management Practice Leader, Management Concepts

Result Chain Diagrams-Tools for PM

2011-11-09T20:34:00.001-08:00

Outcome Driven Models

The above diagram represents in a hierarchical structure, the existence of projects in an organization. As seen, projects help an organization achieve targets/business goals set out by the organization in harmony with their core strategy and in order to achieve the organizational vision. A carefully set-out project helps an organization to stay in business but we have known that far too often, project failures can also bring an organization to its knees.

In my opinion, a project is set out to fail when companies do not see projects in the above hierarchical structure. Any project, if well-defined, should be able to deliver some business goals that need to be achieved. Far too often, the scope of a project is defined so broadly that people fail to see what it is supposed to help them achieve.

Such failures can be avoided by a method called “ result chain analysis”. The result chain analysis is a method that helps clarify business benefits of a project and ways that these benefits can be achieved.

Result Chain Concept:

A result chain diagram carefully depicts the links between business goals, objectives and initiatives that need to be undertaken in order to achieve these objectives and thus business goals.

Layout of Result Chain Diagram:

Ground Rules:

1. Activities / Initiatives should start with a verb to indicate that it is an action item, e.g. “understand current market dynamics”.

2. Objectives should be measurable outcomes that need to be achieved to get to a business goal, e.g. “potential competitors”. It is important that these be measurable so the progress can be tangibly monitored.

3. The business goals should be the final desired outcome which is more strategic, e.g. “achieve 10% market capitalization by 2012”.

4. Each activity / initiative should have a connection that comes out of this activity and ends at a one or more outcomes, this depicts that the particular action helps in achieving the outcome that it points out to.

5. One outcome may result in another outcome. As such, there can be a connection between two outcomes where a link comes out from one and ends at the other.

6. The model aligns from left to write. As such, the business goals (or the final outcomes) should always be at extreme right.

Limitations:

The result chain diagram is not a timeline. As such, it does not show time required to perform a certain activity or even the chronology or sequence in which these activities need to be performed. However, it can depict dependencies which can indirectly point out a sequence of action items.

Example of a Result Chain Diagram:

The Right Tools for the Right Project - Top Rated Project Management Apps

2011-11-09T20:15:00.000-08:00

With the project management approach picking up its steam globally, and more virtual teams coming together to complete work, the leading providers of mobile technology and cloud computing offer user-friendly and effective tools to manage workloads and assign tasks.

In this blog post I will summarize the top rated project management apps for various platforms based on my own experience and user reviews.

iPhone/iPod platform offers numerous project management gadgets.

· Mindtools (free): teaches/reminds you of tools in project management, strategy, decision-making. It’s a comprehensive toolbox for a project manager (or an MBA student) MY FAVOURITE!

· Merlin Project Management (free): a companion product for the project management software Merlin on Mac. In offline mode you can read all data. MY FAVOURITE!

· HoursTracker ($2.99): Time Sheet: allows project management team members to track their hours by punching in and out using their iPhones. I find this tool very handy.

Google Project Management Apps for Windows or Mac:

· Manymoon (free): The tool offers integration with Gmail, Google Docs, Google Calendars and other Google Apps. It promises to keep everyone in sync with shared tasks & files, securely collaborate with the team & clients, and increased effectiveness with organized projects and tasks. Check out their instructional video here.

· Gantter Project (free): web-based Project Management Tool that requires no software to be installed and it completely integrates with Google Docs. The app claims to have “all the power” MS Project without users having to buy or install anything. This app is compatible with MS Project files.

· TrackMyHours.com ($8.95/mo): an hour tracking and billing system designed for businesses and consultants. The tool also helps to generate invoices and export them to QuickBooks.

There are at least 60 Project management apps in Google App store for PCs. Browse them at your leisure (or under time pressure) and see which one meets your needs.

iPad Project Management Apps:

· Project Wizards Merlin (free): - the best rated free project management app for the Mac platform. It offers companion products for iPhone and Mac OS X. Allows to attach photos, display and update tasks and view the projects in a Gannt format.

· My Projects LITE (free): allows users to easily manage tasks, projects, priorities, workflow status, and more. It can also import and save as a CSV file.

· Idea Sketch: allows you to doodle your way to project management. You can create multiple drawings and link to each as you wish, as well as many other features.

· Project Manager: according to the user reviews, it is a “simple and intuitive project management system”. Each project gets a list of action items and each item has other detailed sub items for easy use.

· Gantt Lite: allows you produce gantt charts “the 2.0 way”.

For more reviews on free and paid iPad Project Management apps, visit this page: http://mastersinprojectmanagement.com/25-incredibly-useful-ipad-apps-for-project-managers/

Android Project Management Apps:

· Project schedule ($6.00): monitors your projects and schedules daily tasks in a gantt chart

· Project Management App (free): helps users to manage projects in various locations. Particularly, the app focuses on project, client, contact and invoice data.

· TeamworkPM ($2.99): is an online teamwork application that provides the latest activity on current projects, star most important projects, assign tasks to users, share and collaborate.

And this is just a start. With the right tools for your preferred platform, your project management process will be a smooth sailing!

Problem Management

2011-11-09T14:46:00.000-08:00

Effective Problem management plays an important role in reducing the quantity and duration of service disruption in an organization. However IT Organization (ITO) leaders often confuse between Incident and Problem Management leading to more service disruptions for longer durations.

Incident management aims to restore service quickly by reducing the duration of disruptions. Problem management on the other hand aims to prevent service disruptions by discovering the causes (or potential causes) of disruptions and creating workarounds and permanent resolutions to them. If you do not have both, then you most likely have more user downtime, lower customer satisfaction, and higher costs than you should, all of which reduce ITO Return on Investment (ROI).

Problem management starts with incident management and while they are not the same thing, the two are quite interdependent.

The Dependency:

Incident Management is often like a “one shot” process that starts in response to a report of service disruption, and ends with the eventual restoration of the service. Its goal is restoration of service, and capturing information which can then be used by Problem Management. Problem Management on the other hand is an “always on” process, where in you continuously examine information from any source that has or could initiate an Incident Management cycle. Its goal is prevention.

Without Problem Management, ITO staff maybe faced with “fixing” the same issues repeatedly. Without Incident Management, ITO staff has limited data for analysis and cannot focus on Root Cause Analysis (RCA) and other prevention activities. One without the other usually results in more user downtime and steals valuable ITO resources away from efforts to add business value.

The improved efficiency achieved from Problem management can be used to free valuable resources that can be utilized for other business-aligned projects (innovation) thus making tangible contributions to the success of your firm.

Following discrete Incident and Problem Management processes decreases call volume and reduces outage duration. These improvements can shift the balance between innovation and “Keeping the Lights On” (KTLO) enough to produce visible improvements in ITO business contribution, while freeing resources for focus on adding value beyond basic operations.

Properly focusing on the objective of each (restoration vs. prevention) and making their goals a priority will ensure that this does not fall off in response to the day-to-day pressures of supporting users.

The following are some of the steps can be taken in an ITO to improve problem Management:

1.) Reassess your understanding of Incident and Problem Management.

Consider how you currently operate with respect to restoring and preventing. Understand the objectives of Incident and Problem Management and what it means to your firm and ITO.

2.) Assume that currently you combine restoration and prevention activities with little formal management over either.

In most ITOs, prevention efforts receive much lower priority than restoration efforts – even though prevention can reduce restoration efforts significantly. It is also common to fail to collect accurate information from each Incident Management cycle.

3.) Investigate current activities to validate your assumption findings.

Attempt to document the average duration and number of outages, user downtime if possible. Do you have management objectives of each? What percentage of effort do you expend on each? Is your team capturing the information required to reduce their workload? Are they actively working to reduce outage duration and number of outages?

4.) Assess the capabilities of your staff

Determine if there are 1) methods in place to record all Incident Management details, 2) any formal method for developing workarounds to speed resolutions, and 3) preventative activities such as trend analysis using Pareto Analysis (a.k.a. the “80/20” rule.) More mature ITOs include formal RCA techniques such as CFIA, Ishikawa, Kepner-Tregoe and others.

5.) Start a service improvement program that formalizes Incident and Problem Management as distinct processes.

Ensure Incident Management tracks and gathers information Problem Management will use for trend analysis – software support tools are critical for this. Ensure that you allocate enough time for trend analysis, and that there is a process for gathering industry information to identify potential disruptions

Organization for Problem Management:

Organizational structure plays a significant role in the success or failure of Problem Management. Correct organizational structure is critical to success, however firms probably should not reorganize to achieve it.

ITOs often confuse process and performance. Traditional ITO structures make little distinction between task descriptions (process) and task execution (performance). Research shows that often firms attempt to form two groups: Incident Management (triage) and Problem Management (root-cause analysis). The flaw in this approach can be increased outage duration, loss of organizational knowledge, damage to camaraderie, loss of management visibility, human resource issues, higher costs, and reduced communications.

A federated approach is often better than dedicated departments. One solution is a federated approach that leverages existing staff and capabilities as shared resources to form virtual organizations for resolving problems. This approach however requires defined roles, responsibilities, and a common oversight.

In summary, Problem Management is much more than simply resolving an outage. Its reactive and proactive tasks span multiple departments and even incorporate suppliers and vendors. Focusing first on Incident Management, and then Problem Management can lead to higher customer satisfaction through improved service quality, as it improves working conditions within your ITO.

Reference: Mastering Problem Management by Hank Marquis, Global Knowledge

Top practices favoured by IT project managers

2011-11-09T04:05:00.000-08:00

After watching two webcast and interviews; I have documented some common top practices favoured by IT project managers. They have found them to be very fruitful & improved to crop out consistent outcomes.

1. Act immediately on prioritized task

Usually project manager position is challenging and responsible in nature. Usually, they implement airplane mode; avoid attending personal calls during work hours. It yields to productive work and allows to addresses the targeted issues. Each task is assigned with a priority like action task (must to be completed now, and measurable start & end point) or deferred task (completed, but not now; identify the time to be completed). It has also been revealed that PM acts on each matter urgently with prioritized task.

2. Use project management tool

It is the tendency that every IT projects are guided by project management tools like MS Project/ intervals under the leadership of PM. It requires the people to use & contribute it. This tool is viable across the team from designers to developers, to assign and manage tasks with serious due dates, and to track all of the project life towards launching. It is one of prime supplement of successful project.

3. Hold meetings with purpose

During the project life cycle, it is always wise step to meet only if it is required because time is quite precious during this phase for both PM and team.

- Purpose of the meeting should be clear before organizing meeting with clear agenda.

- Review discussion points before closing the meeting.

- Recap action items and set delivery dates

4. Define and check scope & assumption

Define project scope clearly as soon as possible with signatured agreement, which make sure that every contributors are also in game plan. Clarification is documented. Deliverable falls within the scope. Define assumption along with goal and & intermittently reviewed during project life cycle to make sure functionality and process for delivery still accepted by client. If it is not or there is some alteration; then it should be reflected into change request to client & employee.

5. Version control – cvs/git/svn

This is one of the safety guards against accidental hazard faced in source code. Sometimes due some reason, we end up in working code to buggy code. If we have already implemented any type of version control & checked out the version; then we can recover the old edition of source code. Hence, it gives the sound support in using version control, no matter how small or large the project.

6. Testing

It is recommended to always test application before delivery / launch of application. There had been various cases that people have failed to exhibit the working product during delivery/ presentation. Hence, it is suggested to test in prior to delivery. Considering example, Mississippi State Tax Commission filed a lawsuit against Fairfax, consultancy because the automated tax revenue system that the Fairfax built didn’t work without "multiple incidents of both a critical and serious nature," according to the lawsuit.

7. The Hidden Costs and Dangers of the Shortcut

In IT industry, it is frequent that employee runs out of time leads to pressurized to complete the tasks. However, if in absence of skilled or experience PM, the wrong shortcut may end up costing you a lot more than expected in form of hidden cost.

8. Using ROI to Evaluate Project Management Training

The monetary measurement (ROI) can be done in order to evaluate the efficiency and effectiveness of an investment made by a company. Investments category varies like financial, employee pool, equipment, and training programmes etc.

9. Communication

There should be consistent communication channel with back up alternative for certain situation. IM, Email, Skype & cellular calls are most frequent form to be in team loop. The goal of efficient communication is to make sure that everyone on the same page and can form conversation in need.

References: Webcast & interview - By John Reeve (PM), Pelago Webdesign

- By PMP, Nuwave Technologies

Parth

Controlling Change Requests in Projects

2011-11-08T21:50:00.000-08:00

Changes requested once a project is underway are an inevitable part of any project. They can either be the result of external changes in the business or they can be internal changes requested because the original aims of the project were not clearly defined or understood.

Change requests resulting from external factors are usually beyond the control of a project manager and there is usually little choice but to deal with them. Most successful project managers will have already put a process in place at the start of the project to handle such requests and the plan will be flexible enough to cope without unduly affecting the final outcome.

But change requests resulting from internal factors should be handled very differently. In an ideal project many of these would have been avoided by ensuring the project objectives were well-defined, the requirements were clearly documented and communicated to all stakeholders, and the stakeholders understood what to expect from the final product. Of course, we don't always live in an ideal world and no matter how thorough and detailed the initial stages of a project are there will always need to be an effective change process in place.

Nevertheless, good documentation and clear communication of the project objectives and requirements will minimise the number of change requests.

So what is the best way of controlling change requests in a project and still being able to deliver the completed project within an acceptable budget, time and scope?

Distinguish between the Necessary and the "Nice to have"

The most important element of the change request business case is the expected benefit, which should indicate the value that will be added to the project by the change. This, in itself, will indicate which changes are likely to be necessary. It is important to recognise the description of some business cases may not necessarily benefit the project in terms of time and budget, but are necessary for the client to remain competitive in their marketplace.

Better designed solutions, or nicer, more attractive features are not benefits unless they can be backed up by how this will have a positive impact on the project budget and schedule, or a positive impact on the end-user's effort required to complete regular tasks. Typical questions the business case of a change request should answer are:

"What external business change has resulted in this change request?"

"What internal factor has resulted in this change request?"

"How will this change affect the time taken to complete the project?"

"How will this change affect the use of the end-product?"

"What cost-savings will be made by implementing this change?"

Avoid wasting time and effort

The most obvious way to avoid wasting valuable project resources on excessive change requests and the whole change management process, is to ensure the project starts with clearly defined objectives and requirements. It is also important the criteria which will be used to determine project success is documented succinctly at the start of the project. Ensure all of these documents are distributed to stakeholders and end users and that copies are easily accessible.

Schedule time into the project plan for dealing with change requests and if that time has been eaten up then defer outstanding requests until the following week. Ensure that all interested parties know this is how the process works.

Have clear acceptance and rejection criteria

Use some clear criteria to screen out those requests that will not, or cannot be, implemented. One essential criterion is a business case, so any request without one can immediately be sent back to the requester. Do not waste time tracking down the requester to find out what the business case is. It should be their responsibility to provide it initially (even if you later need to have discussions to refine it).

Be prepared to back up your reasons for rejecting change requests with a well-thought out description of why there is no case to include the change. Stick by your decision unless the project sponsor is prepared to increase the budget or time available for the project.

But do be prepared to be flexible and negotiate a trade-off by dropping a planned task in favour of the change when no budget or extra time is available.

Always apply project management best practices throughout every area of a project if you want the highest chance of success.

V. Nougaret

Learning from the mistakes: Postmortem of 99 IT projects

2011-11-08T14:02:00.000-08:00

A study by R. Ryan Nelson,Professor at the University of Virginia aggregatesthe knowledge gained from 99 retrospectives conducted in 74 organizationsreveal the most common mistakes and suggest best practices for more effectiveproject management. The projects studied have ranged from relatively small tovery large (multi-billion dollar). This study has pulled out some veryinteresting statistics showing 45% mistakes are people and 43% are processrelated leaving behind the product mistakes 8% and technology being the lowestwith 4%. With an odd but in line with the statistics, none of the top 10mistakes was technology related, which means technical expertise by itself rarelyensure project success; instead, project managers should be, first andforemost, experts in managing processes and people. The next interestingfindings was that scope creep couldn’t make on top ten despite it is cited asone of the biggest problem in project failure, however, it is to be noted thatpeople and process related mistakes occupied on top ten indeed dilate the scope,which suggests that project managers should pay attention to it. The lastinteresting finding is that the top three mistakes occurred in approximatelyhalf of the projects investigated, which are (1) poor estimation and/or processscheduling means failure in sizing or scoping the project, estimating theeffort and time required (2) ineffective stakeholder management meanschallenges in managing the involvement and expectations of diverse stakeholdersand (3) insufficient risk management refer to failing to identify possiblerisks and prioritize them to plan and monitor accordingly. The remaining sevenmistakes are in sufficient planning, shortchanged quality assurance, weakpersonnel/team issue, insufficient project sponsorship, poor requirementsdetermination, inattention to politics and lack of user involvement that arepresented in an ascending order. Among the top ten, the team came up withrecommendation for top seven mistakes that occurred in at least one-third ofthe projects. For first mistake the team suggested to develop time boxes toshorter and smaller the projects that are easier to estimate, then create awork breakdown structure to help size and scope projects and finally a projectmanagement office to maintain a repository of project data over time. Toimprove stakeholder management the team suggests to use a stakeholder worksheetand assessment graph, this tool helps to prioritize the most importantstakeholders whose need have to be fulfilled that determine the success of theproject. For risk management project team can use a prioritized risk assessmenttable, big project can employ a risk officer to play devil’s advocate—to lookfor the reasons that a project might fail and restrain managers and developersfrom ignoring risks in their planning and execution. For a better planning acomprehensive project charter, clearly defined project governance, andportfolio management are essentials. For quality assurance automated testingtools and daily build-and-smoke tests are helpful, it is a process in which asoftware product is completely built every day and then put through a series oftests to verify its basic operations, which will save time by reducing thelikelihood of three common, time-consuming risks: low quality, unsuccessfulintegration, and poor progress visibility. And finally for better projectsponsorship it is pivotal to identify the right sponsor from the very beginningthen securing commitment within the project charter and managing relationshipduring the life of the project.

prepared by: S. R. Khan

Management Innovation for IT project managers

2011-11-08T09:57:00.000-08:00

Management Innovation for IT project managers [1]

IT projects compared to other types of projects are characterized withuniqueness, emergency, one shot, short term and uncertainty. For this reason,to get successful results it is very important to find and solve relevantproblems and innovation in project management plays an important role in thisregard. This role is very critical in both planning and implementing the projects.As a result it is very essential for the IT project management to be seen as asystem. Management innovation enablesproject managers to make all the factors in the project interact effectivelyand efficiently with each other to create synergy.

One of the reasonsfor high percentage of failure in IT projects goes back to lack of clearunderstanding about project manager’s role and his or her required skills.These skills are not necessarily limited to technical sets but are even morerelated to managerial sets. To use these skills the main question is to knowhow IT project managers can innovate in their project management methods. Clearlyspeaking the more versatile a project manager the more successful he or she andas a result the more efficient the project. Here come managerial skills andgreat personality even before IT technical knowledge. A competent projectmanager has great communication skills, strong leadership, love of work, clearvision, excellent team building capabilities, structure, alignment and discipline.He or she is interested in every one in the team, the individual needs and values,opinion, feelings and ideas. He or she also invests in motivating every one,creating excitement, making it fun, showing the end point to the team and keepingthe team focused on that. A strong project manager needs to keep her or hisrelations with all the stakeholders in the project, the managers, the clientand the team members alive and active. Some of the major problems from theperspective of project management are lack of communication with the client,passive communication with the management and sole attention to the projectteam members’ performance. Separating clients, management and team memberscould be the main source of unsuccessful results in executing the projects. Butwhat are the things can be done to enhance the efficiency of projectmanagement? It seems that giving regular visits to the client to know about therequirements and their changes in time, flexible communicating with themanagement and paying attention to all aspects of the team such as recruiting,informing, communicating, atmosphere creating and proper activitydistributing as well as cross culturalmanaging can help a lot in this regard. All these factors enable the projectmanager to be effective for the needs of the stakeholders to be met. Using thesemethods properly needs the project managers to be innovative and versatile.

[1] ManagementInnovation of IT Project Managers, by Shuangqin Liu, BusinessSchool, Hohai University, Nanjing & Business School Lianyungang TechnicalCollege, ianyungang, China.

2010 3rd International Conference on Information Management, InnovationManagement and Industrial Engineering

Ways To Keep and To Get a Project on Track

2011-11-07T22:38:00.000-08:00

So often, we hear of projects failing and in retrospect (and with an outsider’s view), and the reasons are very easy to identify. What can future project managers do to avoid this, and if they find themselves getting off track, how can they get back on track?

First, track the critical path (the activities most vital to the project’s success). The more time you spend on identifying what these activities are, the more likely you are to stay on track. A second way to help the project stay on track is to set milestone metrics when tracking objectives. In order to define proper metrics, discussing with those who are involved in the day to day tactics will help identify what those are. A third way to ensure the project is on the critical path, is to continually ask questions to the subject matter experts. Their opinion is a good indicator of the progression of the project.

Now the question is what to do when a project is off track? There are a few different methods to deal with projects that are falling behind schedule:

Re-allocate or swap resources: Generally if a project is off track, it is deviating from the critical path. Therefore, pull resources from other activities to get these vital issues back on track. There also may be an issue with the wrong resources being used for an activity. If a person is not a right fit for an activity, you can find a more appropriate role for them or release them from the team.

Check time-constrained activities: These activities are those that do not change length of time regardless of the number of resources you appoint to it. Identifying these helps to validate your time-frame.

Double-Check Dependencies: This means to examine whether a particular activity is dependent on another one being completed prior. You may discover that there may be invalid dependencies that are unnecessarily lengthening the process.

Prevent Scope Change: Since most projects tend to fall behind schedule or go over budget due to the team working on more than was initially planned for, it is possible that the team is doing things that were not agreed upon. As a project manager, ensure that your team is only working on tasks that were initially part of the project. No energy should be devoted to non agreed-upon tasks.

Improve Processes: Seek feedback from your team to determine where they think the internal work processes can be improved. They are the ones doing the day to day activities and will know best if they actually get a use out of a particular step.

Work Overtime: You may just have to play catch-up if you are behind. This is more useful if you are near the end of the project and just need a final push. If you are at the beginning, then one of the above strategies may work better.

In addition to these suggestions, you may also increase the budget, decrease the scope, or push the deadline further out. However, if you consistently check to see if things are on track, you should be able to complete a successful project.

http://www.techrepublic.com/blog/10things/10-ways-to-get-a-slipping-project-back-on-track/436

http://www.projecttimes.com/lisa-anderson/how-do-you-know-if-your-project-is-on-track.html

Implementing an EMR system within Healthcare

2011-11-07T09:45:00.000-08:00

Canada Health Infoway

Founded in 2001, CanadaHealth Infoway was established tofacilitate the creation of a national electronic health record system that wouldconnect information gathered from various points of patient care and build acomprehensive electronic record of a person’s medical history. Electronicmedical records (EMR) can not only increase collaboration & informationsharing between health care providers and thereby improve quality of care, butcan also enhance overall system efficiency by increasing individual provider productivityand reducing service duplication.

Low User Adoption Rate

Despite these advantages however, and the$1.6B dollars invested in building the infrastructure for e-records adoption,implementation at the community level has been very slow in comparison to othercountries. In 2009, only 36% of Canadiandoctors were using EMR systems compared to over 90% in Australia, the UnitedKingdom, New Zealand, and the Netherlands. A number of factors have contributed to low user adoption rate; theprimary ones being the need for training to change work processes, lack ofadequate government funding, and contractor failure.

v Lackof IT Training

In many hospitals and physician offices, doctors usea familiar system with colour-coded patient charts, which allows them toquickly look for information as required. Having to transition into a computerized system is a challenge becausethe learning curve needed to master digital records to the same level thatphysicians are currently working at with physical files is quite steep. Andthis transition not only applies to physicians but also to thousands ofpersonnel working in healthcare, including nurses and unit clerks, who have tobe retrained to handle new equipment and new operational procedures.

v Lackof Adequate Funding

Dr. Brian Day, president ofthe Canadian Medical Association, and Richard Alvarez, CEO of Canada HealthInfoway, cite lack of government attention to information technology in healthcare for the low adoption rate. The $3Bdollars that has been allocated for this project is insufficient, according toAlvarez, who states that implementing digital recording in doctor’s offices,hospitals, and labs across the country will likely cost about $10B. A portionof this funding can help private clinics deploy the necessary technology. Muchof the funding though should help doctors deal with the inevitable delays intheir practice during the transition period from physical to electronicrecording.

“Many doctors are often surprised by thetemporary decrease in the number of patients they are able to see during atransition period that could take anywhere from 12 to 18 months.” states Dr.Robert Boulay, president of the College of Family Physicians of Canada. “Thisis the real crux of the implementation issue. So what the College really hasbeen trying to advocate for is for increased support for physicians whilethey’re making that transition”.

v Contractor Failure

Any funding for additionalsupport is of little consequence, however, if EMR system providers are unableto provide ongoing reliable service. Indeed, many systems offered by government approved providers havefailed, forcing physicians to relearn and adapt to multiple EMR systems. Some vendors refuse to make modifications to theirsystem to meet doctors’ needs, which not only reduces system usability, butalso discourages system adoption.

BestPractice – Project Implementation Strategy

Many health information and technology experts statethat a national electronic health record system will likely not be realized inCanada for another 20 years or more. Nosingle, definitive reason can fully explain why full-scale system adoption is achallenge for Canada compared to other countries. A combination of factorscontributes to this issue, and must be taken into consideration to increaseuser adoption level.

For one, communicationbetween government sponsors and healthcare providers must be improved upon toallow for greater understanding regarding project goals and expectations, aswell as health system operational needs and resource requirements. Government funding for the project shouldalso be increased to support frontline healthcare workers and incentivize themto transition from physical to electronic medical recording. Australia, for example, was able to greatlyimprove physician participation rates by supporting system implementation, notsimply IT acquisition, and offering incentives for providers to submit claimselectronically.

Furthermore, EMR vendorsmust be better regulated to reduce risks to primary care practices. Perhaps vendors should adopt common datarecording standards to allow for smooth transitions if system changes areneeded. Guidelines, standard procedures, and government regulations should alsobe in place to help healthcare workers understand how best to deal with issuesregarding security, accessibility, confidentiality, storage, and destruction ofelectronic data. Overcoming these hurdles may help Canada along its journeytowards establishing a national electronic health record system.

Posted by C. Liu.

Image Credits:

http://www.wmich.edu/hhs/unifiedclinics/MedicalRecords.htm

http://www.technicaljones.com/EHR_Sept%202009.jpg

References:

http://www.itbusiness.ca/it/client/en/Home/News.asp?id=64334

http://www.cbc.ca/news/background/healthcare/records.html

https://www.infoway-inforoute.ca/working-with-ehr/health-care-providers/emrs

How to get outsourcing right?

2011-11-06T21:25:00.000-08:00

We all know that offshore outsourcing is becoming central to IT. I am sure we understand that offshoring is not something that you can get into and expect it to keep running well.
How do you design and implement a successful offshore initiative? Here are some tips based on articles from experts and my experience on how to get outsourcing right:

1. Never ever outsource your core values:
Always ensure that your company’s core competitive advantage remain within your company. After deciding what you should not outsource, put everything else on the table. People generally believe that only “non-thinking mundane work” can be moved offshore. This is not true! In reality, they can probably move a much wider scope. Make offshoring part of a broad business strategy. The ones who succeed are the ones who have a clear vision of what they want to outsource and have a long term strategy.

2. Fix your process before outsourcing it:
“Don’t try to migrate a process offshore when it’s broken”. Executives at various outsourcing companies advise synchronizing the client and vendor processes and methodologies up front. For instance, if the Client works on an agile model and the vendor works on a waterfall model or vice versa, it may lead to chaos.

3. Find the right vendor:
Teaming up with a compatible partner can make a tough job easier. Many vendors have sprouted up in developing countries, but the difference between good and weak vendors is immense. Given that the prices are comparable, look for culture, domain expertise, financial strength, legal and regulatory compliance, security practices and the ability to provide insurance against eventualities. The key to vendor selection is to deal directly with the people who will be managing your business on a day-to-day basis. Their culture, experience and ability rather than their technology, client list, or offices should convince you.

4. Define clear objectives:
If you are not clear about what you want from a particular project, neither will the vendor be. Use well defined statements of work with clearly specified objectives, service level agreements, escalation model etc. Study and understand the project documents before you sign off.

5. Write talent into the contract:
Some of the outsourcing firms have developer turnover as high as 20% per year. The worst nightmare is to be promised an “A Team” upfront only to get a “C team” in the end. One way to ensure this is not the case is to conduct “Client interviews” and recruit the project teams as well as write a contractual agreement that contains incentives and penalties to ensure that the right talent is available.

6. Acclimate to cultural differences:
Bridging the cultural differences is probably the trickiest issue associated with offshoring. Establishing open, honest communication and spending extra time with potential vendors can be very helpful. Building personal relationships is extremely critical. Regular visits to offshore vendors and investing the time to get to know how the offshore company works can be highly rewarding. Another option would be to ensure that the project leads work onsite from the client location in order to build strong relationships as well as to understand how the Client organization works.

7. Get your hands dirty:
Before plunging your head, companies should get their hands dirty. It would be wise to micromanage the first few small projects in order to ensure that both parties have a clear understanding of each other - the processes, key objectives, deliverables and metrics.

8. Use multiple vendors/multi-sourcing:
If your project is of a significant size, use more than one vendor. The use of two or more vendors is an effective way of driving continued improvement among your vendors. It also acts as a safety net in case one under-performs. You must have an alternate strategy if you are suddenly no longer able to do business with a vendor. Ensure that the vendors are aware of the involvement of the other vendors. This will motivate them, as they will know there is the opportunity for additional work or to lose the work, depending on their performance.

9. Continuously evaluate and measure success:
Set key performance indicators (KPIs) and continually review them. Without tight management, problems can occur quickly. It will always be far easier to manage a project if the KPIs are understood from the very beginning.

10. Plan for a clear exit strategy:
Sometimes, it is possible that the relationship might end prematurely or may have run its course. Either way make sure that your SLA contains a clear exit strategy. It should detail how the outsourced functions should be brought back in-house, clarify who owns what assets and specify when compensation is due, and how much.
Specific to project management, it may be advisable to follow the same project management methodologies between the Client and vendor organizations. It is also advisable to have a Client Project Manager oversee the projects delivered and the standards followed by various vendors, so that it creates accountability while allowing the Client organization to evaluate and measure the projects delivered by these vendors.

References:
Ways to get Offshoring right: Infoworld.com 08.29.05 by David L.Margulius

How to effectively manage an outsourced IT project?

2011-11-05T11:44:00.001-07:00

How to effectively manage an outsourced IT project?

When your business is small and growing to become the next big thing, you have limited budget and workforce and yet numerous positive NPV IT projects that your business needs to undertake. So with the limited resources you have, how do you effectively manage and ensure your projects are completed within the timeline you set and the budget you allocated?

Before you could start to do anything, you would have to layout what implementation options you have because how you are going to do it affects how you are going to plan and manage it. Building it in-house or outsourcing are the two most common options you would have. There are pros and cons of each, so which one should you pick?

In-House Pros

Efficiency: An on-site staff can be reached and communicated with to resolve issues immediately. It is your dedicated resource rather than shared with other firms.

Control: As a full-time employee, the salary is static and appropriate pressure applied could achieve higher productivity.

In-House Cons

Upfront costs: Hiring a full-time is expensive, especially the more capable and qualified candidates cost higher. Usually it is not a viable option for small business.

Outsourcing Pros

Less expensive: Theoretically, it is less expensive than hiring a full-time IT employee in-house. Overhead costs are spread over several clients via the agency model.

Outsourcing Cons

Language or cultural differences: Different cultures and different expectations. Communication issues. The risk of uncertainty of knowing how the outsource firm performs after you have signed up.

Quality Issue: Quality may not be what you expect until you try it out yourself.

So which one to pick? Outsource Locally

As a small business, inevitably outsourcing is the best option to go for since the business could focus on its strategy and core business. However, to reduce the risks associated with outsourcing, it is best to seek for outsourcing in the local region. It provides the right combination of cost savings and monitoring without the language or cultural issues that sometimes arise with offshore firms.

When the Customer Is NOT Always Right!

2011-11-04T19:43:00.000-07:00

Although most of us at biz-schools and throughout our professional careers have been taught the notion of "The customer is always right!", this may not be applicable to many project management scenarios. The project sponsor may be under the impression that they have unquestionable control over the scope, resources, and even the poor PM! This can be a cause of project failure in and of itself.

Unfortunately, many project sponsors, have "selective memory" regarding discussions on scope adjustments with a disregard for their impact on cost, timeline, quality, and resources. As a result, I have the following advice for dealing with project sponsors who are not always right:

Specify what the project sponsor is and is not expected to do: Project sponsors are not supposed to micro-manage the PM. Most successful projects have been the ones with executive support from "start to finish". A project sponsor with strong connections within the organization can be an invaluable ally for carrying the project through completion. This is why a project sponsor exists.

Manage scope adjustments: The project sponsor must understand what the finished product is supposed to have and not have. A good way of responding to frequent scope adjustment requests from the project sponsor is to say "That sounds like a wonderful idea! Once we're finished with what we're working on (phase 1), we'll add that to the backlog of what we could be working on in the next phase.

Attach a cost to scope adjustments: If you feel like your position might be at risk by not agreeing to a scope adjustment in phase 1, communicate how much the change would cost in terms of time, money, and additional resources. More often than not, project sponsors would be more than happy to forgo the adjustments or postpone them for the later phases.

Manage your relationship with the project sponsor: The project sponsor can your your best ally or your worst nightmare! Make sure you nurture your relationship with him/her outside the formal channels of communication of project status meetings.

Reference: toolbox.com

AT&T forgot to test iphone 4 pre-order system

2010-06-17T15:06:00.000-07:00

On June 15th, AT&T launched its online system allowing customers to pre-order new IPhone 4. However, many customers soon realized that the system does not work properly as one hopes. According to industry insiders, with the rush to launch the system as quickly as possible, AT&T ignored to test its new system before going live. What a classic IT Project Management mistake. Read more, here. AT&T's ability to handle the pre-orders has been questioned by many such as here. The manfunctioning of the system resulted in suspension of many orders, reported here. Despite all of this, Apple has been able to sell 600,000 IPhone 4 in one day.

Issues with novel IT projects

2009-11-12T17:23:00.001-08:00

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

2009-11-12T13:24:00.000-08:00

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

2009-11-11T21:08:00.001-08:00

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

2009-11-11T12:31:00.000-08:00

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.

The Next Generation of Project Managers

2009-11-11T01:41:00.000-08:00

So what makes a successful Project Manager? My search on this topic led me to come across an interesting article on CIO.com (CIO Magazine) – “The 10 Key Capabilities of Next-Generation Project Managers” This article provided a different perspective than the many other standard articles that I found which talked about traditional Project Management (PM) skills, people skills, and technical skills. This article focused more on the soft skills required by next generation PMs due to the changing nature of the PM role itself.

Business conditions are changing, which in turn are changing the role of PMs and the required skill sets. According to Mary Gerush of Forrester Research, “Organizations are striving to achieve faster [software] delivery without diminishing quality or increasing.” As a result, there is an increasing shift from traditional software development to Agile development methodologies. This is a new development approach which is more iterative in nature. Requirements and solutions evolve through collaboration between self-organizing cross-functional teams. In this environment PMs serve more as a facilitator role where their focus should be on improving collaboration between these cross-functional teams and removing obstacles to allow team members to get their work done. The traditional control and command approach of PMs is not suited for this environment.

Another changing business trend is companies are driving to make business and IT processes leaner. Companies are looking at ways to streamline their processes to focus on delivering value. This means that PMs must be flexible enough to adapt their approaches to changing business needs. Also, in this increasingly challenged economic environment, resources are getting scarcer and organizations are really starting to scrutinize how every dollar is spent. Therefore, there is an increased focus on the business value that a project delivers. The PM’s role is not only delivering projects on time and on budget, but also ensuring that projects delivers value for the business.

With such changes to the business environment and the changing nature the PM role, this article goes on to provide a list of 10 core capabilities of a next generation PM:

1. Emotional Intelligence: the ability to pick up on interactions (verbal and non-verbal) and events and manage them in the context of the project plan.

2. Adaptive Communication: the ability to articulate ideas (verbally or written) to others using the most effective communication technique for each group. The communication is delivered in the context of whatever is most important to their audience.

3. People Skills: the ability to quickly build and maintain positive relationships internally within the team as well as external stakeholders. The PM needs to know how to lead with influence rather than authority especially since most project members do not report to the PM.

4. Management Skills: the ability to serve, motivate and focus a team, and to foster collaboration among team members. The PM needs to be able to stay focused on the big picture and to prioritize competing responsibilities for the project team.

5. Flexibility: the flexibility and ability to change PM approach or course of action in response to changes in business needs.

6. Business Savvyness: being familiar with the organization’s business, strategy, and industry. The ability to comprehend the strategy and align tactical work around that strategy. The PM should also have to gift of foresight – to proactively anticipate and prevent problems that can jeopardize the project.

7. Analytical Skills: the ability to logically thing through problems and decisions.

8. Customer Focus: the ability to understand the customer’s needs and ensure the project delivers to fulfill those needs.

9. Results-Orientation: the ability to get things done efficiently and effectively. The PM should be pragmatic and focus on what they can get done with what is available to them.

10. Character: the PM should have an appealing personality with a strong and moral character. This is critical especially since the need to engage and communicate with others becomes even more so important.

To succeed as a next generation PM, one will need to flexibility to change with business needs, the ability to deliver on business value, and also these capabilities listed above.

Sources:

Levinson, Meridith. " The 10 Key Capabilities of Next-Generation Project Managers" Oct. 21, 2009.
Website - http://www.cio.com/article/505594/The_10_Key_Capabilities_of_Next_Generation_Project_Managers

Levinson, Meridith. “Six Attributes of Successful Project Managers” Sept. 03, 2008
Website - http://www.cio.com/article/447182/Six_Attributes_of_Successful_Project_Managers

Agile Software Development.
Website - http://en.wikipedia.org/wiki/Agile_software_development

Analysis of Microsoft Project

2009-11-10T21:55:00.000-08:00

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

2009-11-10T11:27:00.000-08:00

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.

2009-11-08T21:10:00.000-08:00

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?

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

The Failure of Virtual Case File and the FBI

2009-11-08T12:44:00.001-08:00

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).

Different approaches of building WBS

2008-11-04T12:10:00.001-08:00

After project scope is defined, WBS is the critical step to bring the project forward. This article will discuss about an overview and comparison of the different WBS approaches and provide my personal experience of developing WBS for the informational systems in an Asian company.

About me:

I worked as an IS (Information systems) developer, SD, SA, and project manager in the information center of Chunghwa telecomm., the biggest telephone company in Taiwan. I was in charge of a number of IS projects, with overlapping schedules. I was also a product manager for Promise Inc., a global storage technology company. As a product manager, I am also handling each product line as an individual project. Through my five years project-related experience, I have adopted several of the WBS approaches mentioned below.

The Overview of the WBS approaches:

The activity-focused WBS approach
This is the most common approach in my company. This approach mainly uses verb and noun. From the conceptual level of project scope, the work is gradually and sequentially divided into separate tasks, which could be managed and accomplished individually. While the top level presents the higher level overview, the bottom level presents the most detail tasks.
The activities clearly describe the “action”, i.e. “what to do”, yet it’d be easy for the project manager to focus too much on the activities and neglect the tangible and measurable deliverables.

The process-focused WBS approach
Instead of focusing on the tasks covered by the project scope, this approach focuses more on the business processes which are required to accomplish the tasks defined in the project scope. Therefore, the deliverables will be analyzed according to each process individually. The combination of all the deliverables from each process will be the final deliverables for the project
The advantage of this approach would be that it clearly depicted how things should be done. The disadvantage is that the analysis of each business process can not tell an overall picture of project activities on a given stage.

The deliverable- focused WBS approach
This approach only uses nouns instead of verbs. Rather than focuses on “what to do”, ti focuses on “what should be done”. In other words, it cares more about the final deliverables instead of the actions leading to the deliverables.

It is a result driven approach, ensuring the deliverables satisfying the project requirements. However, the weakness would be that it’d result in too much focus on the trivial deliverables while neglect the efforts and the complexity of the tasks required to achieve the deliverables.

The outcome-focused WBS approach
This approach focuses on the outcome, i.e. the desirable effect resulted from the activities. Based on the target outcome, the required tasks and activities are planned. The strength of this approach is that it directly targets at the desired effect; the weakness of this approach is that the “desired effect” is usually hard to define and measure. It’s not easy to tell what tasks could result in the desirable result.

During the work in the IS development, we adopted the activity focused approach mostly in accordance with the Top-down SDLC we applied, since we almost built every individual IS from scratch. It clearly expressed the conceptual views at different levels, which is also convent for a project manager to present to different stakeholders’.

However, during my term working as a dedicated OEM product manager, most of our OEM products are customized from channel products. Therefore, most projects could refer to other similar projects. As a result, instead of conducting top-down activity focused approach, I mostly adopted the deliverables-focused approach in that most of the deliverables have been finalized in other projects and the customization would only change few of the deliverables.

To sum up, different approaches could be applied for different focus of the projects. However, the ideal recommendation would be to utilize more than one approach for the WBS in that the comparison of different approaches would compensate the weakness of each other and help project manager to prevent the negligence.

Typical IT Project Management Pitfalls

2008-11-03T17:58:00.000-08:00

The survey by Standish group revealed that only 29% of IT projects achieved success over the last 20 years. Experienced project managers, Project organisation and researchers have attempted to trap the essence of what is behind these failures and have found the factors discussed below with the impact of each factor:

Lack of the right resources with the right skills
Any project however good planned is doomed to fail without right resources with the right skills. Researchers have found this factor the cause of most of the project failures still this is the most common mistake that most organisations make. "All the planning in the world won't overcome an insufficiency of talent" says Joel Koppelman, CEO of project management software vendor Primavera.

Lack of experienced project manager
This factor may bring the project in a zone where it is almost impossible to take it in control. Once in this zone, even the best project manager may feel difficulties. The solution to this problem is to hire the competent project manager.

Not following a standard, repeatable project management process
Lack of methodology increases the risk of falling of tasks related to the project through the cracks. This also increases the risk of reworking and thus meeting the deadlines in terms of time and costs.

IT gets hamstrung by too much process
When there are too much of processes to be followed by team, the teams become inflexible and their inflexibility frustrates stakeholders, which leads to communication gaps and further delays in the project completions.

Poor definition of the scope and not tracking changes to the scope of the project
If a project's scope isn't well-defined by the business and IT up front and When the changes to the scope are not tracked through organised structure and changes are incorporated without any analysed, the project keeps on growing in every aspect i.e. complexity, cost, time line etc. and ultimately reaches the stage of its fall before the completion.

Lack of up-to-date data about the status of projects
Anything that cannot be measured cannot be managed. For managing anything, we need to know the status of process i.e. whether it is in control or moving out of its ranges and only measurement can provide this information.

Lack of analysis of dependencies between projects
There are often dependencies on other projects going on at the same time. When project managers fail to see the dependencies between projects-such as staff assigned to one project are needed on another, projects get held up. Such slowdowns can have a ripple effect on all projects.

Unreasonable deadlines
IT sets itself up to fail and gets a reputation for not being able to deliver projects on time. We have seen this in the case discussed in class that how Mike, the project manager tried to accommodate the project deadlines set by the Board members. But tampering with dependencies and the plan only creates even more problems thus delivering the project on time even more difficult

Incomplete Project Schedules
The factor creates the chaos in the whole process of project execution. Team members don't know what is due when, which makes completing the project on time a challenge.
Lack of Communication with project sponsors and stakeholders:
This factor creates a kind of misunderstanding about the deliverables and ultimately leads to the failure of project. A project is considered successful if it meets the requirements of the stakeholders and end users.

References: http://www.itbusiness.ca/it/client/en/Home/News.asp?id=49310

PM at The City of X

2008-11-03T17:54:00.000-08:00

Having completed a Computer Science degree, you’d think they might have covered project management skills. However that is not the case, as the work consisted mostly of algorithms, encryption (yuck!), and other nerdy things. Therefore when I began my career at The City of X (municipal government) post-graduation, I knew nothing about PM; so much so that it could have hit me over the head and I wouldn’t have noticed.

Shortly after commencing work, I was assigned to a team that was tasked with rolling out the newest version of the ERP system in use, JDEdwards, and was struck by all the planning and meetings that went on. Was it really necessary to meet once a week, just to talk about how things were going? Not to mention the monthly meetings where they invited everyone and Prime Minister. And what about all this documentation? It really seemed like they were trying to make more work for people! Do we really need all these signatures to make a change? At the time I thought, ‘cannot they not just tell us what do to and go away for two months while we do it?’ There was also the issue of the steering committee, which at the time seemed like a bunch of talking heads whose role was to check in on each other for comfort’s sake. What a bunch of bureaucratic fluff.

Flash forward eight years; was I ever wrong. What had seemed to me at the time like a lot of wasted time and effort was in fact the flawless execution of project management procedures and skill. My ill-informed perspective was unable to see the value of all those meetings, documentation, and communication. I naively assumed that all projects ran that smoothly, even in the absence of all that ‘extra’ work we were tasked with. In reality, those procedures led to successful projects; time after time. Communication was effective and structured, everyone knew their tasks and expectations, and issues or concerns were communicated immediately to the appropriate individuals. The PM procedures delivered IT value to both internal customers and taxpayers; ensuring that large projects ran smoothly, on-time, and on-budget.

McDonalds’ “Innovate Project” failure

2008-11-03T17:33:00.000-08:00

McDonalds’ “Innovate Project” failure
Most companies don’t like to reveal their failures of IT project management, but they would learn an important lesson by analyzing their project failures.

History
“Innovate Project” was one of the most expensive and extensive information technology projects. This project aimed to create a real-time global network to link over thirty thousand stores in 121 countries to headquarter by Intranet. This system would collect real time information from every store and then deliver it to the headquarters’ executives.
This information would enable headquarters’ store manager and executives to effectively and consistently manage and operate their stores moment by moment.
Innovate project started in 1999 with a budget of $1 billion and a five-year plant. In late 2002, McDonald's cancelled Innovate. The $170 million that had already been spent for the Innovate project was lost and between 100 and 200 contractors and McDonald's employees working on the project might be dismissed or reassigned.

Mistakes and comments
Scope Management
In the stage of initial analysis, the project management might not carefully consider whether or not the project had the right scope and the project could address the current issues.
Establishing a real time global network to cover all locations was impossible from the beginning, because individual countries had different IT infrastructures.
Project scope should have been defined more in detail to identify viability of project.
Stakeholder Involvement
To identify project feasibility and define its scope, sufficient information and feedback from store managers in each country should have been given. Project team should have identified whether or not they could address current challenges through the feedback.
Project Manager
It’s very important to have a qualified and experienced project manager in the project such as this. If a company had had a skilled project manager, project manager would have told executives that Innovate Project was impossible, illustrating the need to examine the project feasibility thoroughly from the beginning.
Executives Understanding
They understood the importance of Innovate Project to improve daily operation management but did not have sufficient understanding of IT technology and had unrealistic expectations...

Conclusion
The failure of McDonalds’ Innovate Project clearly illustrates that project scope management is necessary to complete the project successfully. Project team and executives should have sufficient understanding of the project and its scope should be well-defined in order to deliver a valuable product within the expected time frame and budget.

Reference:McDonalds: McBusted–‘TURNS AND RETURNS’ by Larry Barrett, retrieved October 31, 2008 from baseline website: http://www.baselinemag.com/c/a/Projects-Supply-Chain/McDonalds-McBusted/3/

Summary of the AT&T Self Destructive Upgrade Project

2008-11-03T17:00:00.000-08:00

Since November 23, 2003, under Federal Commission rule, customers of a certain carrier have the rights to keep their original phone numbers even if they switch to another carrier. Under this external complication, the already problematic upgrade project of AT&T’s CRM system collapsed which cost loss in revenue, loss of customer to its competitors, loss of reputation and high turnover (layoffs). As one of the older phone service carriers, AT&T has slipped from being the market leader to a second ranked carrier with market share dropping of 25% to 17% from 2003 to 2001. To catch up with their competitors, AT&T started to upgrade its phone network that can not handle data transfer through phone to a new network-global system for mobile communication or a GMS that added capacity to global compatibility to overseas providers. However, the transition was not well accepted by customers. To improve not only the quality of customer service, but also the efficiency of customer service representatives, AT&T started to upgrade its complicated CRM (Siebel) to a highly customized Siebel version 6 with software that has an integration tool holding the systems together. This Siebel 6 still could not meet all customer representatives’ expectations. In spring of 2003, they started the project called “Odyssey” to move over to the new GMS and Siebel 7.5 that they were developing. This upgrade project, involving roughly 15 systems, had a bad beginning. Changing the system to web based was a complex and large scope project because it required ripping off all the links which were established in Siebel 6. Creating each new link would require at least 20 or more people to write up. Another problem was that each team worked independently. Sometimes one team would finish testing a part but would find the code of some other parts changed. Also, there was rumour of outsourcing and future layoff that lowered the morale of employees leading to low productivity. Staffs even looked for other jobs during the project. A new project manager had replaced the former CIO which intensified problems employees were having. AT&T should understand that for such a complex project to succeed, they should have a flexible schedule and a back up plan while there was the portability requirement on Nov 23, 2003. Also, the portability required AT&T to work on system that integrated with other carries. Other top carriers decided to employ TSI Communication. However, AT&T chose NeuStar before the announcement of other carriers’ decision. This resulted in an integration problem later on when TSI modified its system and NeuStar could no longer communicate with the TSI. The complexity of the project, abandonment of some testing, confirmation of the layoff, outsourcing rumour, the inflexible schedule and complication of portability issues led to the failure of the project. The failure of upgrade project and the problem of NeuStar integrating with other carriers caused the company to lose 50000 customers per week and an estimated loss of revenue of $100 million because of the lack of service. Finally, AT&T undersold itself to Cingular at $41 billion.

By Cheuk Ho

Experience with a runaway project

2008-11-03T14:04:00.000-08:00

Most of the projects fail either because they are – a) Not able to finish in time, b) Are cost overrun, c) Are below client expectation.
I would like to analyse the only project failure that I have experienced in my previous company in India that provides technical solutions to major financial institutions worldwide. The company has a flagship banking product in its name along with major clients across globe and has repute for delivering zero defect solutions. One of the existing clients came up with the need for a system, similar to CRM systems that are getting widely implemented, that would help them in assessing and fulfilling mortgage requirements of emerging corporate with an inbuilt feature to verify collaterals requirement for the given loan amount. This story is pretty interesting and unique because this project had consecutive failures at various phases but was never discontinued or acknowledged as a failed project. Let me divide the project into phase1 which was the first time the project started and phase 2&3 when the project went to a different vendor after initial failure and came back to the original vendor after second time failure.

Phase1: The project was first started following standard project management methodologies, however at a later stage scope creep resulted in a disaster. The requirements were not clear, nor were the scope or associated risk. Client changed the requirement frequently, the deliverable deadline slipped, people lost motivation and the final deliverable had a quality that was far below acceptable limit. This resulted in the project to be lost by my company to one of the competitors. The project team was penalised for under performance by giving no hike for that year, at a time of tech bubble when rewards used to be huge. There was frustration in the company from top management to bottom as this was the first time in the company history that a project resulted in an unhappy client. This meant loss of future business with this client and a poor brand image for the company.

Phase 2&3: This project went to the competition, but the executive team from the client side remained the same. The same level of uncertainty in requirements led to a second time failure of the project. This gave an opportunity to my company to cover up for the past mistake and try to win client’s faith. The business development team approached the client with the goal of getting the project back to the company anyhow. This meant making unrealistic commitment about the deliverable timeline of eight months (6 days a week, 10 hours a day) , cutting down on the budget by 80% and committing to deliver the design for the next phase of the project for free. A top level management planning team decided that all the members from the old team who worked on the project earlier will be pulled into this project since they knew the system better and this meant lesser time for learning curve. Those team members felt that they got a chance to prove their worth. This project was a bundled project where the budget was fixed. Adding extra resources meant loss to the company. Despite that a team was formed with 75 people that included design, development, testing and management. The group head was involved in weekly meetings of the project and the CEO had been tracking the progress of the project. The high level involvement reflected the criticality of the project for the company.

Though the project was executed following standard infrastructure, good communications, with proper project management tools by adhering to key roles; it did not succeed due to poor estimation of budget, time and scope assessment. The management tried to follow best practices and also covered up for the mistakes done earlier. However they failed to realize that employee motivation was an important aspect of project success. The project failed on various dimensions of time, cost, client dissatisfaction and low morale of employees. It was a runaway project which kept on taking resources for three years and was ultimately dumped because the management finally realised that the existing technology could not support the project need. My company did not make any profit on this project. It simply helped them in getting their records clean with the client who finally walked away by accepting the deliverable as one with agreed upon quality and expectation. We however came to know that the project was never implemented at the client’s site because they realised that in three years their requirement had changed significantly and there was no way they could live with the technology that was getting obsolete and would lack support from Microsoft in future.

Role of marketing in project management for consumer software

2008-11-03T11:17:00.000-08:00

As we all know, one of the key components of successful project management practice, whether for enterprise software or else, is the inclusion of the end-user into the design process. Projects that neglect this component often end up with products that fail to meet the desired functionality criteria and suffer from low adoption rates, if not get rejected as failed projects altogether.

An industry held back by project management

This holds especially true for consumer software. The examples I will use are from my favourite industry: video games. The design process of a game, which you can think of as consumer entertainment software, is fairly complicated. From the conception of a game idea to the end product, there is a long process with many tough decisions to be made about the final characteristics of the game. Project managers go through this long decision tree with the ultimate goal of making choices that will resonate most with the end users. Ironically though, most of the time they have to make these decisions without actually consulting with the end users. The role of traditional marketing in the industry is somewhat limited to focus group studies and beta tests of limited sample sizes. Given the length and complication of the typical project, however, it is very easy to misinterpret these limited directions over time, or to forget them altogether.

It is entirely for this reason that many games turn out to be commercial flops. At best such disconnection with the end-user needs results in a product that cannot sell itself to the consumer. Advertising and push marketing are typically employed to push sales, while advertisement spending reduces the ROI for the project. The perfect example to this situation is the biggest player in the market: Electronic Arts. It has been announced by the company very recently that they would lay off some 600 employees after millions of loss incurred, despite an increase in revenues. Obviously, someone has been doing something wrong.

A surprising example of best practice

Taleworlds is an independent video game developer of very recent fame. They owe their fame to the success of their game Mount & Blade. The remarkable thing about this game is that the development team consisted of only two people, Armagan Yavuz and Ipek Yavuz, and this game was their first ever project. Working with a shoestring budget and zero advertising, they achieved sales of 40,000 units from their own website, and their future sales potential is forecast to be around half a million units after they have been picked up by a well known publisher. In an industry where so many games with million dollar budgets and huge development teams with top notch talent nosedive in sales, their rate of success is unheard of.

They owe their success to their inclusion of end users into the design process. Their unique business model allowed them to start selling the game even as it was in pre-alpha stage, with the catch that purchasers would get all the future updates for free. Furthermore, they established an online community where the users could have a direct dialogue with the designers, and the end-user ideas could go directly into the game without any mediation. New ideas from the design team also got immediate feedback from the customers. The end result was a game with nothing but truly valued added features. Still some people in the industry cannot quite understand why a game that seemingly lacks graphical bells and whistles can sell this well. The answer is that they found the right bells and whistles that mattered to the end user, not to the gut sense of the project management team. Compared to the industry average, their ROI is staggering, all for this little detail in project management philosophy.

By Taylan Kadayifcioglu

Comparing Microsoft Project to Web-Based Project Management Software

2008-11-03T11:15:00.001-08:00

“If you are benchmarking or comparing Microsoft Project to newer web-based project management software, here are 3 key factors to consider when reviewing this type of project management software.
1. Difference in Philosophy:
Microsoft Project’s philosophy keeps the traditional project management paradigm but patches the tool with collaborative features. It has many robust project planning and resource allocation tools. However, it is very much a project manager’s tool. It is geared towards people with training both in project management methods and in using Microsoft Project PM Software itself.
A good example of this is that the collaborative features in the software are not real-time. Information needs to be pro-actively published either by the project manager out to the team or from team members back to the project manager. Practically speaking, the project manager and team members work on their local copies of MS Project and then submit or publish their work to the server.
This adds in an additional layer of adoption and is an extra task that managers and team members need to manage on a project. It does add in some collaboration to the information flow of project management but it reduces some of the benefit of having collaborative project management software by adding a barrier to the flow of information (and it creates more work).
2. Multiple Components:
Microsoft does not offer Microsoft Project as an ASP or Software as a Service model. To use Microsoft Project PM Software a company needs to buy multiple components and host it themselves. These components include desktop copies of the software, a copy of the server software, non-project manager licenses, Microsoft SharePoint Server software and MS Windows Server software.
Project management software like Vertabase Pro, which is native web-based software, can be purchased on an ASP (also called On-Demand project management software or Software as a Service - SaaS). Licenses to use the software are purchased on an annual basis and it runs on any browser or operating system. That means the project management software can work on Mac OS or Windows operating system. It can work using Microsoft Internet Explorer, Apple’s Safari browser or even Mozilla Firefox. Further, there are no additional components to buy or install.
3. Training and Support:
Training and support must be purchased separately for Microsoft Project PM Software. In many cases, training for Microsoft Project can cost thousands and thousands of dollars. Since the software is designed for more experienced or professionally trained project managers, the training is important for people to get the most out of the project management system. If people don’t get trained properly or if there is not a culture or politics enforcing use of the project management tool, the tool can quickly fall into disuse.
Support is a la carte with Microsoft Project Server. It needs to be purchased separately or on a per-incident basis. Support calls for Microsoft Project PM Software are often handled much like other customer support calls from larger software vendors.
Training and support are included with every purchase of Vertabase Pro PM Software, as it is with other web-based project management tools. In some cases, the tools are so intuitive that training is not even needed. Some software, like Vertabase Pro, also includes videos on using the PM software and extensive online help files to get the most out of the application.”

Post by Marcos Souza
_____________________________________________________
Reference: Phillips, Mark - Comparing Microsoft Project to Web-Based Project Management Software – The Vertabase Blog – October 1st 2006

The world’s next “biggest IT project disaster”

2008-11-03T11:08:00.000-08:00

In 2002 the UK government announced a project to build a new computer system for the National Health Service (NHS). Completion was due in 2012 and the original budget set at £12.4 billion. By the middle of 2004, contracts totalling £6.2 billion had been awarded to the following IT companies; Accenture, CSC, Fujitsu, BT, IDX and iSoft – but since then progress has been limited.

The NHS delivers state funded comprehensive healthcare to 60 million people and is Europe’s largest employer, thus a new computer system is no small project. The plan is to replace all existing computers with a system that securely stores data centrally and provides comprehensive medical records that can be accessed anywhere.

Despite recent claims that the project has made substantial progress, latest estimates suggest the cost will now be £20 billion, or an astounding $35 billion! The project is currently running four years behind schedule and has no firm date for going live, although this will now be well into the next decade.

In 2007 a lead Fujitsu consultant stated that there was a danger of the contract delivering a “camel rather than a racehorse”, that the project “lacked visionary leadership” and that the techniques being used were those “familiar for small projects” and that they were simply not working.

The Road Thus Far Travelled

The project lost its first CEO, Richard Granger, who resigned from his $500,000 pa role in 2007, and two of the worlds biggest IT and consultancy firms have also pulled out. Most high profile was the withdrawal of Accenture as lead supplier, who proved that the risks of high profile failure can be so great that firms turn down potentially very profitable work. The second and latest firm to pull out, due to failed attempts to “reset” their contract, is the aforementioned Fujitsu, who earned £256 million from the project in 2006/07 and the decision to withdraw, will cost them an estimated £340 million.

The project appears to be heading for failure, and this raises several questions. Why is it still ongoing? Why, given the statistics of the success of big projects, was it conceived in the first place? And is it possible for a big project to be successful using existing project management techniques?

By Martin Berry

References

NHS computer project will cost £12.4bn
http://www.computing.co.uk/computing/news/2158476/nhs-computer-project-cost-4bn

Boss of troubled £12bn NHS computer project quits
http://www.timesonline.co.uk/tol/news/uk/health/article1942900.ece

NHS computer project troubled by more delays
http://www.timesonline.co.uk/tol/life_and_style/health/article4029206.ece

Bank bailout puts £12.7bn NHS computer project in jeopardy
http://www.guardian.co.uk/society/2008/oct/29/nhs-health

Delays to NHS computer system could cost taxpayers £40bn
http://www.guardian.co.uk/politics/2006/oct/01/1

NHS Computer Project Failing
http://www.lightbluetouchpaper.org/2007/09/13/nhs-computer-project-failing/

£12bn NHS computer upgrade faces fresh turmoil
http://www.independent.co.uk/news/business/analysis-and-features/16312bn-nhs-computer-upgrade-faces-fresh-turmoil-418040.html

£20bn NHS computer system 'doomed to fail'
http://www.telegraph.co.uk/news/uknews/1542486/andpound20bn-NHS-computer-system-%27doomed-to-fail%27.html

Importance of a Project Plan

2008-11-03T10:56:00.000-08:00

Project Plan is a document used by the project managers as a guide to project execution and control. Project plan is primarily used to document the assumptions and decisions that facilitate communication among stake holders, project budget, scope and schedule. A project plan should answer following questions

a. What is the problem that project plan is trying to address?

b. What are the major project deliverables?

c. Who will be involved and what would be their responsibilities?

d. What is the project timeline and what are individual milestones?

This document outlines five simple steps to create a project plan which can act as a checklist and prevent project managers from taking wrong path.

Step 1: Create a task list and Work Breakdown Structure

Project manager often underestimates the total time duration and total number of tasks involved. A good project manager would create a WBS – a Hierarchical list of the project phases, tasks and milestones. A good manager will be able to identify all the phases of the project. WBS is critical because its drives the scope of the project. By properly mapping WBS to individual steps will avoid rework and false starts.

1. Identify the major pieces of the project.

2. Break down the major piece to the smallest individual piece.

3. Identify individual milestones, completion points – at the end of each of the major activity to help measure project progress and for bench marking.

4. It is also important to give names for individual milestones.

Step 2: Indent or Outdent tasks to finalize the WBS

Once the project is broken down into tasks, project manager should prioritize each task. A good task list would differentiate major phases of work called summary tasks and the smaller phases of work called sub tasks. Summary Tasks have sub tasks indented underneath them. Subtasks represent the actual work a resource will do, and they don’t have an additional subtasks underneath them.

Step 3: Enter Task durations or work estimates

Work is the amount of effort or person hours needed to complete the task. Duration is the amount of actual time that will pass before the task is completed. If a task is completed by one person in 16 hours, assuming each day working hours is 8 hours; duration will be equal to 2 days. Units can be either in hours, days or weeks. When duration is entered for the task it is important that the duration is entered at the sub task level estimate accurately.

Step 4: Create dependencies between tasks

One of the most critical steps in scheduling is to create task dependencies, or links. This step makes the difference between a plan that can be used as an effective management tool and a plan that can be used a presentation tool.

A dependency occurs when start or finish of one task depends upon start or finish of another task. After the dependencies are set, you can easily identify the critical path and understand the driving factors of the project end date. You can also see the ripple effect in the project when changes are made to a particular task. The challenge planners have is to ensure that all tasks are in the dependency chain.

Step 5: Assign Resources

Resources are allocated based on the needs and priority of the tasks. There are three possible approaches

1. Use project to show responsibility for tasks: This approach takes the least effort to enter and maintain. However, it does not give you any real insight into the status of work during the course of the project.

2. Use project to forecast resource requirements: This approach requires additional effort to enter and maintain assignments, and also requires assigning the correct work and unit values up front in the planning process. It provides more accurate information upfront but does not provide information about the status of work during the project.

3. Use project to forecast resource requirements and track what work resources actually do on tasks: This approach allows managers to see how work on tasks is progressing during the course of the project.

How to Spot a Failing Project

2008-11-03T07:07:00.000-08:00

With the high rate of failure in project management that 2 out of 5 projects fail and the larger the project, the more failure it experiences. There are some reasons what symptoms tell us project management is going wrong. While the commonly failing reason includes lack of management support and unclear objective, it suggests ten intangible warning signs to look out here:

1. Lack of interest. They have to make it sure if everybody really agreed to where they are heading for and check if they have shared same goals and objectives when conflict occurs. Positive environment helps project management to be successful.

2. Poor communication. If there is formal and informal lack of communication, it can be the warning sign.

3. Lack of velocity. Velocity is key concept in successful project management because it makes tracking progress easier along with imposing a feeling of success and team morale. Jim Johnson of Standish group says that one of the classical signs a project is in trouble is that things aren’t moving.

4. A “no-bad-news” environment. Everybody does not want to hear about bad news. However, if there forms the environment not to spread bad news, the bad news can be slow to reach people and result in fatal outcome to miss the opportunity of correcting that. The acceptance environment of bad news should be established by leaders and CIOs to prevent awful result later on.

5. Concrete signs. Some of the warning signs are visible and obvious. Good organization providing executive visibility has less tendency of pop up trouble in the last minute of the work.

6. A lot of overtime. Overwork is usually used by project manager because it is fast and easy way to fix project management to keep the schedule while no workers welcome it in reality. When team members’ health condition deteriorates, it can be another sign and result of overwork that the project is going bad.

7. Diversion of resources. It can be usually seen that the resource, commonly people, pull off from the project to work other things. Time and resources are limited for the project, so they should be controlled and managed wisely.

8. Ratios trouble. Compare the budgeted time, money and schedule with actually spent or implemented results. It easily let you know where you are and where you should be.

9. Milestones aren’t met. It is better to set the milestone weekly with small piece to get the feedback and concrete result which enables avoiding the risk in the future. The lines of code written are classic example to measure process.

10. Scope changes. For example, requirements can change and it itself is not bad. However, they have to be checked what requirements changes and why they changes to keep the project management in healthy way.

All of the 10 things mentioned above are just sign, and does not mean that project has failed or is about to fail. However, they can be good indicators that needs close attention from project managers and people in the position of responsibility to avoid failure of project management.

Reference
Cook, R. & Johnson, S. (2007). How to Spot a Failing Project. Retrieved from http://www.attask.com/images/library/CIO_Article.pdf

A reliable BI system increases the business intelligence - a PM story

2008-11-03T02:17:00.000-08:00

This is an entry for documenting what I recommend to address a systematic problem in my internship organization. To avoid the concern about the disclosure of sensitive data and situation, the organization title refers to ABC institution in following description.

Background:
ABC institution is a business school who provides the international executive education and business consulting service.

Although ABC’s main product is imaginable product, I still can see a product as a set of activities including 4C (contact, consult, composing, until closing the deals after delivering the courses.).

As the challenges mentioned above, the report suggests tackling those problems by CRM system and knowledge management system. While the systems are the tool to accelerate the effects, they should be underpinned by following main concept.

1) A customer centricity and service to turn “push marketing” into “pull marketing”
The original way we are using right now is a “push marketing”, which means we push the information to our clients, hoping they accept our offers. The idea of the customer centricity is that we boost the sales by raising clients self awareness, providing a central dashboard for each client, showing the information about how competitive they are, in terms of the employees’ talent by converting the total amount of courses the clients (both corporate accounts and individual accounts) have taken compared to the benchmarks in the same industry they have taken. By doing so, the clients would check whether there is lack of some specific knowledge or whether they under the average within same industry, and checking their knowledge inventory. The comparison will raise clients’ awareness or stimulate their human resource planning in a long run. The dashboard will designed to send the core competency reports by a certain period to remind clients’ human resource stuff to increase their business and employees talent by purchasing the ABC institution’s programs or contact with our product managers. Therefore, we are turning “push marketing” into “pull marketing”.

2) A reliable BI system increases the business intelligence
Since the core competency of ABC institution is knowledge intensive, Knowledge management is the key to maintain its competitive advantages. We can use knowledge management to help ABC institution more effectively create, capture, synthesize, deploy, share, and reuse organizational knowledge by a set of activities aided by information technology infrastructures. However, the building of knowledge database is time consuming and could not take place in a single period time; it requires a continually inputs from all employees. Therefore, the report suggests that to design an encyclopedia, storing all information, including key program, new products, and advertising campaign details.
Further, this system can be connected with CRM system as well; for example, after the representative fulfill the questions, the report can be sent to customers by email, leaving a very clear message.

3) Automations to reduce the product leading time and unnecessary people error
The essential factor to implement the automations is to digitalize every single data. The best way to achieve this goal is to have the digital inputs in the very beginning. Although ABC institution has introduced the intranet, some of the information still needs to be keyin manually such as the enquiry from callings. To solve this situation and to connect with other suggestion mentioned above, we can initiative the digital inputs from the business leads, both the leads generated from online inquiries, offline seminars, and clients referrals.

4) Knowledge managementto reuse the developed knowledge and, to increase FDC’s business intelligence automatically
ABC institution is a place bound with lots of brilliant people, producing the knowledge and business solution all the day even the operation itself keeps producing business intelligence as well. However, those knowledge is scatted everywhere, moreover, no process to record those intangible assets automatically, in result of less utilization of ABC institution’s assets. To address this problem, the knowledge management is recommended to apply as the supply chain management for retailers. For example, first, to input the existing data such as the competitors portfolios, seminar performance documents in a systematic way, the KM system then automatically prioritizes solution documents based on "usefulness-frequency of use" in resolving specific problems; the higher priority ones rise to the top of the list. The automatically prioritization can apply to both customers service receiving the callings and the product managers developing the programs for companies. In the result of prioritization, the knowledge can be shared and improved by different people (a good example is Wikipedia and the economic emerging due to Wikipedia); further, the “most frequency questions”, “the most popular/ useful/ common business solutions” will be read, applied, updated as well so that FDC shaped the (the best practice would be Google’s searching ranking methodology that weights the ranking of most popular web pages based on users, surfers’ clicks, assuming that the web pages which earn the most clicks imply the most useful web pages for certain keywords.
In general, the one effective way to build what every reliable BI system needs- a single version of the truth; therefore, to create a data warehouse, a central repository that is fed by various systems of the company (mailing list, sales, alumni portfolios) and reflects a definitive picture of what is happening is the most essential element.

Modeling the New Procedures
This report is an initial study for internal communication improvement. Although the intention is original form couple divisions, it extends the scale that embrace the whole organization; further, the completed implementation can improve not only the internal communication but also increase the business intelligence. Moreover, by highly utilize the knowledge assets, reducing the service lead time and so on, ABC institution can build the foremost competitive advantages; for example, “providing solutions in 7 days”, “monitor your business intelligence in real time”.

1. Providing solutions in 7 days.
Since the problems in companies are inclusive in couple aspects such as “internationalization”, “marketing”, “finance” and so on. We can document the solutions that we already developed for reusing it on the similar case so that we can reduce the lead time of delivering products.

2. Monitoring your business intelligence in real time.
When our system is designed for customer-centric, every companies or individual can have an account which records what kind courses that have been taken, and how competitive you are in terms of knowledge capability and so on.
The member also can see other companies’ record as the benchmarks.
Those two functions would build the core competency as well.

Implementation
To implement this project, it requires a experienced IT vendor to support the equipment, developing, and maintenance. To choose the ideal vendor, I recommend either outsource to the original vendor who support ABC institution’s existing intranet system or host a competition, distribute part of this report to candidates as a guild line, asking them to propose a feasible solution and price.

IT project experience - establish CMS for exchange program

2008-11-02T14:54:00.000-08:00

While working for the Japanese Consulate in Vancouver, I coordinated a project to establish a Contents Management System for an exchange program run by the Japanese government. The Japan Exchange and Teaching (JET) program was established some 20 years ago by the government, and it has been recognized as a very successful program in promoting cultural exchange between Japan and more than 40 countries in the world. The program invites foreign youth to Japanese municipalities to experience Japanese culture and to teach foreign languages at Japanese public schools every year. From Vancouver, about 100 Canadian university graduates are annually sent to Japan on the JET program. The program aims to promote the understanding of Japan at a grass-roots level in foreign countries.

In fact, among the past JET participants, there are a quite few who have become quite successful in the fields of business, education, and politics, in their home countries. However, the Japanese government has done a poor job of maintaining contact with these former participants. Recently, losing contact with past JET participants has been recognized as a great loss for the program. Under such circumstances, the government decided to establish a CMS as a tool to keep a bond with the past, present, and future JET participants around the world. The CMS will contain all the contact information of the JET participants and connect the web pages of the JET alumni association as well as those of the Japanese municipalities and government. After almost two years of debate on the project in Tokyo, the budget was finally approved for establishing a CMS. Since the IT vendor, which was a company owned by one of the of JET alumni, is located in Vancouver, I happened to be assigned to coordinate this project.

Although the project looked fairly simple at the beginning, the completion was delayed and was more than a half year behind schedule. The main reasons for the delay were the legal aspects associated with the project and the difficulty of managing the IT vendor relationship. On the legal side, we had to consider a number of issues, such as the location of the server and protection of personal information. We had to understand when we set up a server for the CMS in Vancouver, what kind of legal impact it would have on the users who are in different countries. We had to also be concerned with how much privacy protection was to be given to personal information in the CMS. Since neither the IT vendor nor I had any experience in similar projects, we almost had to learn everything from scratch. The IT vendor and I consulted lawyers, and it took more than three months before we understood the legal environment and agreed on the basic framework of the project.

Managing the IT vendor was also extremely difficult in this project. This small IT company, run by a JET alumnus, had been involved in this project from two years ago. This company spent a lot of time and resources debating with the Japanese government even before I got involved in this project. When I began working with this company, their motivation level was very low. Further, due to budget constraints, the government said from the beginning that they could not pay competitive fees to this company. Thus, this project work always remained low in the IT vendor’s priority list. This made it so difficult for me to deliver the result by the scheduled deadline. I was always going back and forth between the government office in Tokyo and the IT vendor to make progress on the project. Finally, after two years, the CMS was released with an eight month delay in the schedule.

I found this project a very tiring experience since I had no choice but to work with an unenthusiastic vendor and a limited budget. I always had to worry about the payment schedule since the budget for each quarter could not be carried over to the next quarter under the special budget allocated for this project, but I never knew when the vendor would be able to show us the scheduled partial deliverables in each quarter. I felt many times that there was no way to complete the project. After everything was over, looking back, I wonder if I could have gained more management buy-in on this project. This seemed impossible at that time, since my direct supervisor was extremely busy with something else and did not have interest in this project. As there was not any strong support from the Tokyo office, I felt this project was imposed on me only because the vendor was in Vancouver. After all, not only myself but the people who worked for me and the IT vendor had a very hard time throughout the duration of the project. If I had a similar opportunity in the future, I hope I could have more buy-in from top management and effective support in order to better manage the project.

Project Failure Prevention: 10 Principles for Project Control

2008-11-02T13:59:00.000-08:00

Project Failure Prevention: 10 Principles for Project Control

Tom Gilb in his article describes that a lot of projects fail, no matter if they are engineering projects or software engineering projects. He describes 10 principles for project control that if used wisely, can save a lot of projects. Here is a summary of those principles:

P1 – Critical Measures
This principle states that the critical product objectives need to be stated in a way that they can be measured. The project needs to have a well-written set of top-level requirements which include the critical product characteristics with a set of measurements for those characteristics. For example, in the objectives one can say that the firm needs state-of-the-art security, but it is much better to state that the firm needs 99.89% reliability.

P2 – Pay for Results
This principle states that the project team has to be rewarded to the degree the project achieves the critical product objectives (described in P1). The author states that project teams when do not deliver specifications or when schedule is not met, usually management gives them more money or more time to finish the requirements. Team are being rewarded with more money or more time when results are not good. The author suggest the contrary to “punish” them when requirements are not met.

P3 – Architecture for Quality
This principle states that there is a need for a top-level architecture process that will be the guiding parameter for the whole project. That top-level architecture process has to specify design strategies to enable the critical product objectives. This principle is concerned in building good foundations for the project.

P4 – Clear Specifications
This principle states that the specifications have to be super clear. The specifications have to be clear enough that they can be tested, they have to be unambiguous to the intended readership and that there should not be any unintentional design requirements. The specifications have to be easy to read for any kind or reader.

P5 – Design must meet business needs
This principle states that the specifications have to be carefully reviewed to see if the designs meet the business needs. Again, designs should be well written and easy to read. After reviewing the design, an analysis has to be made to see if the business requirements are going to be fulfilled with the design. Detail is needed so there is no confusion in latter parts of the project. The design has to have resource estimates.

P6 – Validate Strategies Early
This principle states that high-risk strategies have to be validated in early stages of the project. Those high-risk strategies are the ones that will impact the levels of performance and cost. Also those strategies are the ones that can ruin or make a project fail. To validate strategies, project teams can build pilots, trails, experiments, prototypes, etc. This principle is the one related to Risk Management.

P7 – Resources for Designs
Resources like money, human effort and calendar time have to be allocated carefully to meet the required design. Each design and each project have specific characteristics, and good resources are not necessary good in some situations, so the resources should be allocated according to the design, they have to be allocated to enable the design.

P8 – Early Value Delivery
This principle states that the stakeholder value has to be delivered as early as possible. The author suggests that projects have to be planned in an evolutionary way. The most basic requirements or objectives should be done first, and around those, the new phases should be built.

P9 – Avoid Unnecessary Design Constraints
This principle states that requirements and specifications should not include unnecessary constraints that could impact performance and value. This principle suggests that the designs and solutions should impact business needs instead of being done to satisfy technical designs. The author suggests that projects should use the technology to satisfy requirements, not the other way around.

P10 – Value before Bureaucracy
This principle states that “the project should be free to give priority to value delivery and not to be constrained by well-intended processes and standards”. (Gilb, 2005). Bureaucracy can impact project performance if it delays decision making. Project management should have the power to make fast high impact decisions.

Reference: Tom Gilb. Copyright 2005-2006 by Tom Gilb. Published and used by Methods & Tools with permission. www.methodsandtools.com

The New CRM System - Company PM Story

2008-11-02T11:46:00.000-08:00

I was recently involved in the project of upgrading the CRM system of my company to a more “advanced, interactive, powerful, and user-friendly” one. The new system was launched recently, but already several months overdue and also way over budget. I think it is to a large extent a failed project even though we do have a new system running now.

As a team member, I have observed the following mistakes:
1. The CFO of the company was assigned to be the Project Manager who has no previous project management experience, no IT technical background, and no direct involvement in the sales and marketing group who will be the users of the CRM system.
2. The CFO then oversold to the CEO (who also has no IT background and will not be an active user of the system) the system he was going to purchase and implement. The CEO was mainly interested in the reporting functions of the new system and had high expectations of the effectiveness of the new system, therefore giving his full support to the project. The CFO, in order to gain the CEO’s support, painted a “wonderful picture” of the new system to the CEO, not realizing that many of the functionalities he described were not going to be included in the new system, at least not if a significant amount of extra cost was not incurred to have those functionalities added. Obviously the CFO got the “picture” from the sales people of the company that was trying to sell us the system.
3. The company that was selling the new system then assigned their consultants to start designing and customizing the system based on our needs, and afterwards also migrated the data from our old system to the new system. The consultants were working with the CFO and our IT Manager on the designing and customization phases, but no comprehensive consultations with the sales and marketing group or the CEO. Therefore user needs, expectations, and requirements were not fully understood by the consultants.
4. After a few months of work, the new system was then launched on a trail basis to a limited group of users for initial evaluation. It was at this moment that serious deficiencies were discovered that major functionalities that were originally expected were not included. There was an outcry from the trial users and the CEO demanded those functionalities to be included, only being told that a significant amount of extra cost had to be incurred for that. The CEO approved it and the project continued.
5. The re-launch of the new system was then delayed again and again and new extra costs were added periodically as more and more deficiencies were discovered and had to be resolved. Finally under the pressure of the CEO, the system was re-launched, but as described by the CFO: this was only Phase 1 and more work had to be done.
6. The system is now being used in the company, even though complaints are heard regularly about the user-unfriendliness, the lack of expected functionalities, the deficiencies, etc. It was also mentioned many times that the new system was actually worse than the old system. And as mentioned earlier, the project was far from complete and many more months and much more money have still to be put on this project to try to achieve what the system was supposed to do, if achievable at all.

It is very clear from this case that without using and implementing project management best practices, a project is almost doomed to fail.

Motivation: How to increase project team performance

2008-11-02T01:13:00.000-07:00

There are a lot of different aspects in project management we have already discussed in our course. The team motivation is, however, another important issue which I would like to consider in some more details. Unlike many other issues of project management such as project life cycle, planning, scheduling and etc., the motivation is completely intangible. There is no easy way to formalize or even describe it. Nevertheless, the motivation is so important that I decided to discuss briefly some contemporary approaches which might help you in your career of project manager. I start with short introduction to motivation theories, describe some common motivation mistakes and wrap up with some important team building issues.

There are the following motivational theories for project team management: McGregor’s Theory X and Y, Herzberg’s KITA, McClelland’s Achievement, Affiliation and Power motivation as well as MBTI personal style.

McGregor’s Theory X and Y basically assumes that two types of project team members exist, X and Y. X team members are those who are low motivated and require constant attention form project manager. On the opposite, Y team members are highly motivated individuals who do not need a lot of supervision to get their work done well and on time. The project manager motivation approach depends on which team members’ type, X or Y, he works with. The disadvantage of this theory is that typical project team environment is a mix of type X and type Y individuals which require a project manager to accommodate balanced leadership style to effectively motivate both types in the same environment.

Herzberg’s KITA (Kick In The Pants) motivation theory is based on the idea that both positive and negative motivators exists. The project manager has to use “carrots” (positive KITA) and “sticks” (negative KITA) to motivate the project task completion. Advantage of this approach is that the project manager is able to create the atmosphere of goal achievement which drives the project success. Disadvantage of such motivation is that it creates “I am ok, you are not ok” relationships between PM and team members. The competition and lack of trust, resulted in that, may destroy the cooperative atmosphere in the project team.

McClelland’s Achievement, Affiliation and Power motivation framework is focused on individuals who are oriented on personal achievement, driven by comfortable work with others (affiliation) or motivated by power. Each type of these individuals has specific potential advantages and disadvantages for team dynamics. The theory explains how the project managers may effectively deal with all of these types.

MBTI personal style or the Meyrs-Briggs Type Indicator provides the ability to identify the personal motivation styles of project team members. Knowing these styles, the project manager could apply personalized approach and task direction for each member of his team. The sophisticated personalized motivation is the main advantage of this approach. The disadvantage is that it takes additional efforts to make necessary individual assessments.

You may find the more detailed description of all motivational theories described above in the Internet.

Typical motivational mistakes which I would like to mention are the following:
o Whatever motivates me – will motivate others. The result of this mistake is disappointment in team members who behave differently;
o People are motivated primary by money. PM are typically constrained in giving monetary rewards so they have to look for non-monetary motivation tactics;
o Team members love to receive formal awards. Other project team members might react negatively on such type of individualized recognition. Be very careful with that;
o The best project leader is the strong cheer leader. Though generally effective, this approach could not be applicable in problematic situations and might cause the opposite results;
o I will treat everyone the same. All individuals are different in terms of culture, experience, education etc. Individualized motivation is more effective in such environment.

Important team building issues in project management to mention here are the high-performing teamwork and the building team culture. High-performing teamwork is based on the high involvement of the team members on the all stages of project life cycle such as planning of tasks, time estimation, risk reviews etc. The involvement of the team provides the project manager valuable insights about the complexity and arrangements of the project efforts. Team members would feel much more ownership and acceptance of the team efforts as well.

Building high performing team culture is another important issue to focus on. The following steps should be accomplished to create good project team culture:
o Team processes – defining common team processes with well known performance expectations and standards;
o Celebrate team successes;
o Foster trust, teamwork and open communication;
o Recognize team members’ strengths – the project tasks needs to be assigned according to individual strengths, knowledge and motivation;
o Promote Project Success – continually identify the successes the team has accomplished (no matter what the size of these successes is).

To sum up, the PM must recognize the importance of individuality for effective project team motivation. Based on my experience this is the key to effective and successful project management.

Reference:
Peterson, Tonya M. Project Management Journal, Dec2007, Vol. 38 Issue 4, p60-69
http://search.ebscohost.com/login.aspx?direct=true&db=bth&AN=29413504&site=ehost-live

Lessons from Relaunching an Online Community

2008-11-01T18:42:00.001-07:00

Background

In July 2007 I undertook a project to relaunch a web site for an online technical community. The 30,000+ member community consisted of application developers, report designers, dashboard designers, and IT administrators. There were three full-time employees (manager, colleague, and me) on the team, plus one somewhat technical contractor. The contractor was hired originally to help with some site design and maintenance, and given the shortage of available developers, I brought him on the project, even though I had my reservations about his technical abilities. As project manager, I had two main goals: 1) perform a technical migration of the underlying platform, and 2) redesign the look, feel, and navigation of the site.

The Project

I plunged head on into the project, developing and ranking business, user, and technical requirements, identifying stakeholders, developing project plans, and creating page layout designs and navigation flows. The original goal was to relaunch the community just before the user conference in early October, which gave me 3 months to pull this off. I was excited about making my vision of the community happen even though I had never managed a technical project before. After identifying all the requirements and getting sign-off from the key stakeholders, I worked with our contractor to identify all the customized code modules and then asked him to determine how to implement the same functionality on the latest platform. The customizations proved difficult and time-consuming to resolve and put the project 4 weeks over schedule. I was not going to make the early October launch so I revised the schedule again to target a late November launch, although I did not actively advertise this.

We had set up a development server with the latest software and had started to build out the pages by early September. Over the next month we tackled one technical issue after another but the issues never seemed to cease. I felt I was spinning many extra cycles putting out fires, making design changes, building and modifying pages at the expense of communicating with stakeholders, for example. In retrospect, by not committing to a launch date I allowed myself to be in constant develop and test mode. I learned that I should have prioritized better what I needed to accomplish and also held the contractor responsible for delivering on time. Better yet, we should have paid him a set amount for the project, contingent on delivering as agreed upon. Upon further reflection, I also made the mistake of looking to him to manage the project because I felt I was in over my head and not willing to take full ownership and control over the project.

By late November, I wanted to launch over the weekend. I had a go-no-go meeting with my Manager beforehand, but failed to impress him with my launch plan. It was apparent that there were too many gaps that could have put the community at risk. With a bruised ego, I reset the launch date to the weekend of December 8 and 9. By now I HAD to launch because we were way over schedule. During this time, I was contacted by our web marketing team. Based on an initial discussion, I made the mistaken assumption that they were not interested in my project but they came in at the last moment to request that all the designs follow the corporate standard. In a meeting with the team, I lost my temper as I was told by one member that he was going to recommend that the launch should be delayed AGAIN because the look and feel did not conform to standards. In the end, I pushed through this obstacle and was able to implement all the changes they requested but this was a stark reminder not only to err on the side of over communicating with all stakeholders but also to defend your project. Coming up to the launch weekend, we worked relentlessly to meet all the requirements but I felt I could have “worked the plan” better by being more stringent on the milestones. In the end, we worked all weekend and well into the night and delivered the new site, but had to sacrifice testing time. We did some testing right after we went live and everything seemed to be OK so by midnight Monday morning, we all went home. By the time I woke up the next morning, my inbox was overflowing with email about technical difficulties that employees were having with the site. While the launch was received well overall, we spent the next several weeks over the holidays fixing bugs and other issues.

Key Lessons

My key lessons were to do my homework before making time estimates, “plan the work and work the plan”, commit firmly to an end date, break the project into phases (that is a technical migration phase followed by a redesign phase), allocate generous testing time, hire the right people to be on the project, involve the stakeholder early and often, plan the resources required, and develop a more comprehensive project plan (scope, WBS, etc.) by closely following sound project management principles instead of just doing what I thought was logical.

Review of a Project Management Tool - Change Management

2008-10-30T14:14:00.000-07:00

After reading some blogs about Project Management and some reviews of Project Management books, I realized that a common topic was Leadership & Change Management.

Researching in those topics I found a Harvard Business Review article about change management that talks about the common mistakes that companies make in projects.

Here is a summary of those Common Mistakes:

The first common mistake is to not establish a sense of urgency. A lot of times management do not understand how change initiatives or new projects can drive employees out of their comfort zones. They just want to start the new project without considering the effects on the employees. If people are not motivated, the change initiative will go nowhere. Management has to establish a sense of urgency to start and to get good results out of a project. One way can be to present unpleasant facts, like competition gaining advantage over the market. Management has “to make the status quo seem more dangerous than launching into the unknown” (Kotter, 1995).

The second common mistake is not forming a good and powerful team to lead the change effort. First of all, if management is not fully compromised to the project, the change initiative will fail. Management has to be an active supporter and employees need to know it.

A third big mistake is not creating a vision about the new project or change initiative. The leaders of the change initiative have to create a good vision of the project that can be communicated throughout the whole company. That again can be a big problem, if there is a vision, and the employees that will be affected by the change do not know it, and do not know the importance of it, the project will be hard to implement. And most importantly “communication comes in both words and deeds, and the latter are often the most powerful form” (Kotter, 1995

Another mistake is not removing obstacles to achieve the new vision. Management has to think about the obstacles that are going to appear in the process of trying to achieve the new vision. They have to think carefully about all the aspects that can arise, and they have to put themselves in the employee’s shoes to find out the probable problems.

Another big error is not planning for and creating short-term wins. Short term wins foster the motivation of employees. Management has to find out ways to make employees feel that the project is advancing and that results are being achieved.

The last big mistake is not to anchorage changes into corporate culture. “In the final analysis, change sticks when it becomes “the way we do things around here”” (Kotter, 1995).

Reference

Kotter, John. Leading Change. Why Transformation Efforts Fail. (1995) Harvard
Business Review OnPoint, 1-10.

Project Failure - Migration of T-Star

2008-10-29T19:42:00.000-07:00

Project Background
T-Star was a back-office software system for Asset Management Companies (AMC) operating in Japan. Around 80% of AMC in Japan subscribed to T-Star for their daily operations. This project was an application migration project and was outsourced to an IT services provider in India. The estimated project cost for T-Star’s owner was 14 million USD.

Project Scope
This system was to be re-engineered on Java technologies. It was developed using COBOL and had 1.5 millions lines of code. This project was divided into 4 phases (System Analysis, Design, Development and Testing). The total duration of the project was around two years. The team size remained around 35-45 persons including three project managers.

End Result
The project ran for twelve months and was scarped after the end of the analysis phase. All project managers employed by the IT vendor resigned. The vendor also lost market reputation. This resulted into an adverse impact on its Japanese projects.

Key Mistakes (From Vendor Side)
Project Approach
Feedbacks provided by customer on use cases and business requirements on many instances was informal, verbal or were on hard copies. This resulted in confusions and a lot of time was wasted in tracking and managing feedbacks. The methodology selected was object oriented and iterative in nature but it ended up in standard SDLC customized model.
Customer Management
An active customer engagement starting from Sr. management level up to team level was desired. Relationship should have been managed more effectively from onsite (Japan) with dedicated account manager/onsite coordinator from the start of the engagement.
Resource Management
Resources with required skill set were not found on time resulting in poor quality of work. Many crucial resources e.g. Test Lead, SQA expert etc. could not be inducted in time which affected customer’s confidence. Some key resources including project managers left the project midway.
Culture and Language
This project like any other Japanese projects needed managers with prior Japanese project experience. Communication was a big issue as all customer communication was in Japanese. Team members faced language barriers.

Lessons we can learn from this project failure
Before start of any project- deliverables, risks, format of delivery and assumptions need to be clearly defined & communicated to all stakeholders. Set reasonable customer expectations in terms of what would be delivered, how frequently and on what quality levels. Always report issues and problems to the customer, those faced by the team due to lack of clarity in requirements, frameworks or any customer specified items (this was most often ignored!). Further, closure of above issues should be tied up with project schedule and quality of deliverable. Always ensure that enough time is budgeted for internal as well as customer reviews. Take customer feedbacks on time or else inform the customer the impact on schedule & cost due to late feedbacks. Document each and every customer feedback and do not rely on verbal or informal feedback. Set up a dedicated project management office to monitor, track and resolve critical project issues.

It may not be textbook, but it's working so far...

2008-10-28T19:49:00.000-07:00

so, i've recently completed a project which has been working quite well for our company... i'm not sure it can be considered textbook management and implementation of a project, but it seems to be working so far... any advice on how i could have done things differently/better, or what i should be looking out for in the weeks to come would be appreciated... i call it "enhancing the export order management process at company xx"

************

As the Manager for Production Planning and Delivery Execution for a company involved in offshore export, I was recently assigned the task of improving the Export Order Management Process at my company. Like many other companies, our company has over the years narrowed our business focus to our core competencies, and as such, outsource our export logistics to a broker, who manages our export shipments. This means that activities such as booking vessel space for containers, negotiating freight rates and managing relationships with carriers are handled by the broker.
The main challenge with this seemingly straight-forward business process was that our company runs SAP, while our small broker outfit operates on a simple query database within which all key order information is stored. With our broker having better access to real time information, the order management process used to rely on manual query downloads into a spreadsheet generated by one of the broker’s employees throughout the week, from which our company’s export order management and delivery execution was carried out.
The biggest issue with executing on “snapshot” query downloads was that the moment the query was downloaded into a spreadsheet, the data was outdated. That is, because the order management was affected by many variables such as changes in the ship’s schedule, production upsets, and customer changes, there was a need for “real time” data for both our employees and the broker to work off of.
The project was simple in concept: map the current process, identify data inputs (both source and people), determine critical data and who should be inputting the data into a “real time” environment. The real time environ from our perspective needed to be SAP, as this was our single “truth”, and we needed the broker and all other relevant parties to work off of SAP.
When the preceding was completed, I worked closely with an IT Business Architect, who took my business needs, worked with the end users to design the solution, and then went to work with IT Technical for the technical programming.
After 4 weeks of designing and programming, we moved on to a week of testing to create all possible scenarios imaginable and the solution passed the test. Our company now has all key export order management and delivery execution data in SAP, and SAP can at the clock of a button generate real time reports for all key personnel involved in export order management.

Welcome

2008-10-18T10:40:00.001-07:00

Welcome to IT Project Management blog. You will find a list of interesting topics about information technology project management in this blog.