How to Spot a Failing Project

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

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

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

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

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

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

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.