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

How to succeed in projects

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

– Gerald M. Weinberg, Weinberg's Second Law

There maybe some truth to that but if we look at things from a 2000 ft cruise altitude, we may infer differently. In 1628, the grand warship Vasa launched for her maiden voyage. It started as a ceremonial trot around the Stockholm harbor but ended up in a disaster within ten minutes. The Vasa sank, taking many of those aboard with her. Loss of lives, money, reputation, and availability for war were a few of the consequences. Can we blame the shipbuilders as we blame the programmers – or is there a bigger problem, perhaps in the process used to build Vasa or create software programs or in project management method.

It is easy to point fingers but to find the root cause of a failure and use the lessons for the future is the right thing to do. Often, the difference between success and failure is spotting critical early warning signs that a project is in trouble. Rich Cook wrote an article for CIO.com in which he described IT project failures as a fish left too long in the refrigerator, the failure becomes all too obvious. Once the 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 you convert project failures into project success – spot the stinky fish early. How do you do that? – add probes or sensors in your refrigerator that would trigger an alarm before the fish goes bad. Let us further examine what those sensors can be that will help us detect problems on a project. A lot of these are hard to measure objectively as some of these detection patterns come with experience.

Transparent Communication

One of the keys to detecting problems on a project is to have open communication. Managers don't have to wait for a status report meeting to find something is hung up. One key way to facilitate transparent communication is for managers to build trust with the project team members. If a project manager feels that the communication is not transparent, he or she should look at building trust and also keep track of the grapevine messages. Both inter-communications between management with the team and intra-communication between team members need to be healthy. It is the manager’s job to effectively manage both and resolve conflicts before they escalate. "Everyone is allergic to bad news." As a result, it's all too easy to develop a culture where bad news is slow to percolate upward – which deprives management of vital, if unpleasant, information. An environment where bad news is accepted will help build that trust for employees to be transparent. The earlier the bad news is received, the easier and less costly it is to fix the problem.

Project Management Methodologies

Project management methodologies used to run a project could also determine how quickly problems can be detected. Proponents of iterative development (agile project management) focuses on breaking projects into small chunks and delivering pieces of it fast for user feedback – this help to correct the course of the project as there are several milestones and the risky issues are handled first. On the other hand, waterfall model where the entire project proceeds step by step from analysis to final delivery can be hiding problems till no recovery is possible. More the milestones, better the tracking.

Lack of Commitment

Detecting lack of commitment or interest 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 they are doing. Also, the members should understand the goal and vision of the project and should be motivated by the outcome with tied incentives. Inherently, majority of software developers are introverts. Therefore, having a positive energy in the work environment helps. They are also creators so providing them flexibility in terms of work schedule can help them motivate. EA Sports is big on providing their employees with flexible work environment. Although working on a video game can be motivating enough, working to meet strict timelines can be de-motivating. So offering flexibility and additional on-campus services (e.g. gym, dry cleaning, car wash, mani-pedi, etc) helps to get them committed.

Project Management Tools

Moving on to more objective measures, there are tools, which can tell managers of the heartbeat of the project. Managers can use dashboard tools that provide visibility into a project at the click of a mouse. Tools like TargetProcess can help keep track of progress. It works similar to the tracking tools car dealers use when you take your car for servicing. The tool keeps track of every detail of the work that is supposed to done. It tracks who is working on it and the progress from one stage to another. One word of caution is that these tracking tools are as good as how well the employees input their progress. Therefore, proper governance is needed to maximize the use of these tools.

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

Another sign of a troubled project is when an enormous amount of resources are diverted to one project. From my personal experience, I have seen it happen a few times where several new team members were assigned to a “troubled” project. Most of the time this resulted in delays with old members training new ones and the quality of the end product suffered.

Schedule slips can trigger alerts that the project is in trouble. If there are too many reported software bugs that 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 is running into trouble.

All these project attributes can be tracked via a project management tool with active updates to management from the reporters. These project attributes are similar to the smelly fish and the tools are our sensors to detect the smell and notify us of a rotting fish – in this 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

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

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

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

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

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.