The Trouble With Microsoft Project
Having conquered the desktop platform with its Microsoft Office Suite well over a decade ago, Microsoft has done very little to improve its project management software, Microsoft Project. But new alternatives to the de facto project management software for MS Windows PC’s means a better solution may be in your future.
Microsoft Project can be traced all the way back to a DOS version that appeared in 1984. Through its twists and turns in well over two decades marketing the product, Microsoft has released a number of Windows versions and a Macintosh version. Microsoft killed off the Macintosh version back in 1994. And Microsoft Project 2007 (Windows only) is the current release, with a 2010 version for Windows expected some time next year.
By marketing Microsoft Project with its ubiquitous Office Suite, Microsoft has made MS Project the most popular software for project management. It is the most popular, but not the best in terms of efficiency, functionality, or compliance to project management best practices. Microsoft won the .extension war for common applications: .doc for word-processing, .xls for spreadsheets, and .mpp for project documents.
As a result of owning the file format, they are able to dictate what the documents (therefore applications) can and cannot do. Owning the standard also means competitors feel compelled to maintain legacy compatibility with Microsoft Office Suite documents. This has a serious impact on the whole paradigm of competitive applications. Innovation is kept in check. It’s no wonder why, virtually all products that compete with MS Project start up with a screen ready for the user to begin entering a laundry list of tasks and milestones in a Gantt chart view. Although best practice for project planning is to begin with a work break-down structure (WBS), then some kind of Network diagram, and then a Gantt chart, Microsoft Project continues its nonsense. The Network diagram view in MS Project is down right embarrassing (figure below). The boxes are rigid, low-end graphics that reminds you of the mid-80’s. It isn’t surprising that so many full-time Controllers, Marketing Managers, Engineers, HR Directors, and the like who are not formally trained in project management are so ineffective wearing the ‘PM’ hat – not to mention frustrated.
In recent years, advancements in cloud computing, web standards, and more powerful lower cost computers has ushered in a number of excellent new alternative project management tools. For example, software as a service (SaaS) firms likeLiquid Planner and ProjectPlace have leveraged cloud computing and open web standards to offer very powerful cost effective PM tools. These tools work on any modern computing platform: Linux, UNIX, Mac OS X, and Windows. So it doesn’t matter if the project management office in London is using Mac OS X, the JAVA developers in Mumbai are using Linux, and the Procurement department in Chicago is using Windows. All project team members and key stakeholders have easy access to the same version of the truth, and can get their job done.
These new project management tools emphasize collaboration and communication. Let’s face it; most projects don’t fail because of not having enough Gantt charts. No, they usually fail because of poor communication and bad stakeholder management. It is encouraging to see a new breed of developers who get it. Likewise, there are now many very good desktop alternatives for smaller firms who do not manage huge projects and are using Linux, Mac OS X, or Windows platforms:Project X for Mac OS X comes to mind.
No one wants to spend more time managing their software than their project. If you are in this common predicament, consider jumping off the Microsoft Project ship and onto a more standards based, open, accessible solution.
The Big Dig, In A Nutshell
An excellent chronicle of the mammoth project’s triumphs and failures This archive provides a wealth of knowledge about the massive Boston construction project: Big Dig Project (Boston) News - The New York Times. There are many lessons to learn from the project. And, the teaching is there for the learning.
Before: Death, destruction, cost overruns, and legal wrangling
Was the vision and benefits realized?
Why Bad Projects Are So Hard to Kill
Why is it hard to recognize impending failure?
The very nature of projects, something that has never been done before, means there is always a risk of failure. While some projects fail in pieces, cost over runs or late delivery, others fail in totality.
Because projects are often times close to the brink of failure yet they ultimately succeed, sometimes it is difficult to predict abject failure. There are many examples of projects that looked over the precipice a few steps away from total disaster, ultimately achieving great success. Another reason why it is sometimes hard to recognize a project’s impending failure is many organizations do not have processes in place to foresee it. These organizations lack proper controls, and do not collect relevant information. A change in the structure would go a long way to prevent project failures. Similarly, poor risk management is another cause for project failures that go undetected.
Yet another cause of project failures that go unrecognized is “collective belief” noted by Royer. Typically the collective belief begins with the project’s evangelist and continues to grow like a snow ball rolling down a hill. The project’s evangelist with an extensive and strong network, charisma, and a good reputation can fan the flames of collective belief in the project very quickly. Other factors like personal and organizational desire for a “winner” is further strong incentive for people to believe in the project. At this stage, a “group think” emerges that causes everyone to move in lockstep, critical thinking goes out the window and outliers with differing opinions are censured.
Avoidance techniques to limit impact of bad projects
The longer bad projects run, the greater their impact on the organization. Therefore, an early warning sign to indicate a project is a bad one is essential. Ideally, the warning should come very early in the project’s life cycle - the sooner the better.
During the initiation phase or at the point of scope development, rigorous examination of the project’s viability including risk profile must take place: Is the project the best way for the organization to achieve its strategic goals? Are there other projects that can accomplish the organization’s strategic goals for less money, shorter duration and less risk? How does the project’s financial metrics like payback, ROI, IRR, or MIRR compare to the organization’s benchmarks? In addition, a SWOT analysis vis a vis the project, the firm, and market should also be done. If the project passes these types of gates and is executed, key factors like earned value, risk, quality and the project’s standing in the organization’s project portfolio must be continually managed.
Significant changes that are detrimental to the project means the project should be seriously considered for termination. At the completion of rigorous assessment, if necessary the project should be shut down - immediately. This type of objective, rigorous, methodic process will limit a bad project’s negative impact on the organization and its customers.