News & Views

January 4, 2010 from gannthead – “When I first started managing projects, I treated requirements as an input to the project–they would magically appear and tell me what the scope of my project was. It didn’t take me long to figure out that I was taking the wrong approach, that requirements gathering was actually an integral part in the execution of the project. But I am still surprised by how many organizations are unable to come up with good requirements…

…We still only have the functional requirements, what is to be delivered. The project team still needs to determine how those deliverables are going to be achieved…”

180 View – In preparing requirements for our clients, we try to focus on “what” needs to be done rather than the “how.” But sometimes it is believed that there is an optimal “how” and we will document it as a requirement too. For example, an organization may want to analyze their operations across multiple dimensions such as by department, region, manager… – consider this the “what”. One vendor could accomplish the requirement with a segment for each dimension in the account structure/coding block – an example of the how. Another vendor could accomplish the requirement using reporting structures or analysis codes, which for complex organizations is a much better way to get it done.

November 11, 2009 from ProjectTimes – “…Unfortunately, most scope-management frameworks are designed around the definition of a finite scope based on limited knowledge and advocating tight controls to manage change. Scope changes can be driven by many factors, including new ideas, regulatory change, change of needs, poor understanding of requirements, heuristic discoveries, financial circumstances, changes in leadership and more. In addition, in the absence of an agreed-upon objective and quantitative methods, assessing the impact that scope changes will have on the success of the project, emotions and politics will most likely rule the day…

A mature management will want to approach projects in such a way that the remaining time to complete and monies that need to be spent, reflect the most accurate possible appraisal of reality. However, in most cases management wants to cast early estimates in concrete and threaten grave punishment to the project manager should they miss budgetary and delivery date targets. This in turn often incents those leading the project to lie about progress, representing to management that the project-amazingly–is as complete as the monies that have been spent. The old adage that “project progress can be declared on track right up to the remaining 10 percent of the effort” has roots in this contradiction–and management’s stupidity in such matters…”

180 View – This article contains some useful suggestions including “A more mature and sane approach to managing projects is to recognize from the beginning that events can occur that could substantially impact the project’s budget and delivery date. Based on this analysis, a set of planned recalibrations can be forecast, along with the trigger points that would indicate a change in scope was needed. Being proactive in this regard is the key to being intelligent about true scope management.” The trick is to obtain estimates for time and costs to complete the project. The variance should be calculated as Budget – (Actual + Estimated Cost to Complete). Another recommendation (“Time boxing” is a well-accepted method for chunking deliverables into a series of smaller groups”) is a way to find out early whether there are problems rather than wait for everything to be ready at the same time.

October 20, 2009 from ComputerWorld – “CIO.com Senior Editor spoke with Coyne about the ill-fated patterns and emotional traps that most tech implementation teams fall prey to…

CIO.com: With large enterprise software projects, are there patterns that the people and teams fall into?

Coyne: There are very clear patterns. When the project starts, the technology-buying organization sets out clear outcomes that they wish to achieve. You generally see some strategic-looking documents about what a successful project will be: a percentage increase in the way we do this type of process; greater efficiency here; greater visibility of doing business there; faster this, that and the other thing. That’s a very positive stage.

But then what generally happens is the low-level techies get involved – low, meaning detailed rather than skilled. At that point these business objectives get boiled down into technical functions… And generally at this point, there is a loss of vision into why the project was started in the first place…”

180 View – We agree that the business case that launched the project often goes missing during an implementation. But it’s too simplistic to think that there is one reason for all problems. Our top 10 implementation mistakes are:
1. Poor job in system selection process
2. Lack of testing
3. Customization at the get-go
4. Lack of training
5. Lack of knowledge transfer
6. Business goals gone missing
7. Maintaining the status quo
8. Picking the wrong people
9. Missing controls
10. Lack of project management

August 17, 2009 from InfoWorld – “Oracle is devoting two full days and 70 sessions at the upcoming OpenWorld conference to its Primavera PPM (project portfolio management) software, which is used to track and manage the torrent of people, assets, timelines and expenses associated with projects and services engagements.

It’s no accident that Oracle has decided to give such a high-profile showcase to Primavera, which it acquired last year. While PPM software may not be sexy, demand for it is growing explosively. Forrester Research expects what it defines as the “project based solutions” market to reach $6.5 billion by 2010, up from $4.25 billion in 2007…”

180 View – PPM is more than just managing a project. Primavera does that – so does Microsoft Project and many other products. Per Oracle’s website – “Companies turn to Primavera project portfolio management solutions to help them make better portfolio management decisions, evaluate the risks and rewards associated with projects, and determine whether there are sufficient resources with the right skills to accomplish the work.” PPM makes sense for any company with competing projects, and require a methodology and tools to help evaluate which ones to pursue.

September 16, 2009 from ProjectTimes –“There is no worse person to be than the project manager at the end of a failed project. As an IT project manager, I have experienced that feeling and I can tell you it’s not nice. IT projects are particularly difficult to manage. In fact there really aren’t any IT projects, just projects that have elements of IT in them…”

180 View (written by Lawrence Young) – This article talks about the issues that affect the success, and the usual lack thereof, of IT projects. The author talks about the reality that ‘IT projects are particularly difficult to manage. In fact there really aren’t any IT projects, just projects that have elements of IT in them.’

The article further states (with which we couldn’t agree more) that ‘avoiding the common pitfalls of IT project management is not rocket science-it is simply a case of taking some sensible measures’.

The article provides practical advice on how to avoid making the five most critical mistakes when managing IT projects, which require the project manager to:

1. Provide appropriate support for the project
2. Get users involved
3. Stop scope creep
4. Manage expectations
5. Ensure that project participants ‘understand the lingo’

July 15, 2009 from ProjectTimes – “In most organizations, project management is practised on an exception basis. We only think of it seriously when the project is in big trouble. The need for project management, and in some cases, even its existence, is acknowledged only when we are squarely faced with the reality that the project is out of control…”

It is not surprising that, even today, many organizations think of Project Management as just another overhead, full of meetings, administration and paperwork that they can ill afford. It is only in the last 20 years that project management has gained recognition as a management discipline and embraced by professionals and academics as a core competency for managing projects.

180 View (written by Lawrence Young) – This article provides a compelling set of reasons why companies should adopt a formal and structured approach to managing their projects.

After explaining the 10 key characteristics of a project, the author rightfully points out that projects are ‘full of uncertainties and risks’, and that most companies make a concerted effort to manage a project only when the project is in ‘big trouble’. In our opinion, this is tantamount to buying car insurance after you’ve been involved in an accident!

The article points out that the failure of many projects can be traced back to the absence of one or more of these 10 project characteristics i.e. projects are ‘hastily started and poorly executed without a proper foundation, a business need, a sponsor, a customer, a risk assessment or completion criteria. It is no wonder that they are headed for the rat hole right when they started’.

The author also states that ‘implementing quick-fixes in lieu of formal project management is like sending a novice pilot on a flying mission. With little training and experience, the pilot is expected to learn the fundamentals the hard way, in the midst of a crisis, and to fix the problems while the plane is still up in the air! Surely, we cannot succeed with this approach, be it with flying or project management’.

Our decades of experience has taught us that projects such as selecting and implementing business software are often plagued with costly and painful problems and unrealized expectations that could have been substantially if not totally avoided with proper project management.

So if you decide that the success of your project is important enough that failure is simply not an option, ensure that you adopt and promote formal and proven project management practices. Remember, ‘an ounce of prevention is worth a pound of cure’!

August 24, 2009 from NetworkWorld – “This timeless illustration of IT project management just seems to strike a chord, and every time someone sees it for the first time, they recognize its simple truths.”

July 2009 from PM Network – “Typical PMS (Project Management Offices) focus only on project success rates – in terms of on time or within budget – but they need to look beyond those metrics to define how their projects benefit the company. That means looking at revenue, cost savings, customer satisfaction or other business-focused metrics…”

180 View – Finally. It looks like project managers are catching on that successful projects are not just about being on time, on budget and in scope. It’s not enough to do the things right. You also need to do the right things.

June 24, 2009 from Project Times – “Ever start a project without a stable foundation for scope? How did it go? To ensure project success, it is essential that scope be unambiguous and carefully managed. This can be accomplished with the Scope Management Process, which provides a formal set of procedures for planning, executing, monitoring and controlling scope…

Basic functions in the Scope Management Process include reviewing the project charter and other documents such as the contract, statement of work and request for proposal…”

180 View – Anyone familiar with project management methodology will already know most of what’s in the article. The main reason for including it is the discussion of where scope is defined. The article suggests the contract and statement of work as a source. It is extremely unlikely that scope will be defined well enough in either of these documents. The article also suggests the request for proposal. I agree with that but it needs to be part of the contract, which it is usually not. If using the RFP as scope, the requirements in the RFP need to be defined specifically enough to avoid misunderstanding later. The requirements should also be prioritized to ensure focus on the most important requirements.

June 2009 from Project Times – “From PMI Network to blogs all over the web there is a continuing debate over Agile project management. I find it interesting, if not distressing, that the debate still rages. While there are distinct attributes of Agile methods, overall the basic tenets of formal PM are certainly there. Planning exists, there is a clear point of responsibility and accountability, there is monitoring and control (often a lot tighter and more useful than in more traditionally managed projects) as well as a closing. The predominant differences are in the way these are accomplished and the “weight” of the PM activities. The Agile Manifesto values some things over others, for example “individuals and interactions over processes and tools”. This does not mean it seeks to eliminate processes and tools. Valuing the ability of “responding to change over following a plan” does not mean never following a plan…”

180 View – The article is biased to agile project management that includes formal project management as well as being able to not follow it if there are compelling reasons. When I was a bit younger, I was responsible for a multi-million dollar software development project. I was the project manager but I was also responsible for detail design along with a number of other things. I was told by some people that I should be allocating 100% of my time to project management but I never did. It was more like 30%. I was able to reduce the amount if time I spent on project management because of tools that I developed and acquired, and because I was intimately familiar with all aspects of the software. It would be very difficult for anyone on the project team to mislead me. I knew exactly where we stood in terms of quality, scope, timing and budget. So I think project management should adjust to the situation and especially the people involved.

April 27, 2009 from ComputerWorld – “Your company knows that it wants a serious CRM system. But the CFO, nervous about the costs, starts to suggest strategies that could keep things under control. Meanwhile, you know the implementation team has some ideas that go in a completely different direction. How can you manage executive expectations that may be based on misinformation? This two-part article will cover common traps that you should avoid, followed by advice on the best ways to save some real money.…”

180 View – The article makes some good points that apply not just to CRM. For example – “The complete-system launch, sometimes called a Big Bang project, just doesn’t work very well for software. The warning signs of Big-Bang thinking include: Infrequent project milestones; large, complex, monolithic project deliverables; little consideration of political or change-management issues; fake, vague, or overstated requirements, particularly for scope of system integration or historical data; scope creep. Better to deliver incrementally, deploying something of value to the business at least once a quarter.” We believe that during the design phase, you should consider the big picture/bang, but build and roll it out in manageable phases.

June 3, 2009 from itBusiness – “…Businesses of all sizes embark on thousands of projects for new products and services every year. Unfortunately, most projects are doomed to fail outright, or at launch, because the original success criteria were not met. Some project failures lead to delays in product launches, such as the AirBus A380; others, like Boston’s Big Dig, incur huge cost overruns. These examples, as well as the results from survey after survey, show that American businesses have not been able to figure out how to consistently get products and services delivered on time, on budget and with the highest quality…”

1. Definition

It is critical to start with a solid foundation. The foundation must be built at the organizational level and not with individuals. It is imperative that, from the CEO down, there is understanding and buy-in when it comes to defining or redefining the following items:

• Roles and Responsibilities: This can be painstaking, but the effort will pay off when it’s time to execute. The exercise may outline the need to develop new organizational structures to better support efficiency and communication within the delivery teams…”

180 View – There are some good points in the article. We would like to emphasize and expand on the first one – defining roles and responsibilities. You need to be very specific about responsibilities. Consider for example the issue log. Many projects will have an issue log to track issues that arise during a project. Who is responsible to prepare it? Who is responsible to review and give feedback? Who is responsible for approving it?

April 29 from ProjectTimes – “Factual and anecdotal evidence confirms that IT investments are inherently risky. On average, about 70% of all IT related projects fail to meet their on-time, on-budget objectives or to produce the expected business results. In one KPMG survey, 67% of the companies who participated said that their program/project management function was in need of improvement. Why? A number of leading factors for project failure were suggested by the survey, including the “usual suspects”: unreasonable project timelines, poorly defined requirements, poor scope management, and unclear project objectives. Granted, all of these factors can play a role in project success. But are they the cause or project failure, or just a symptom of some larger issue? In this article, we will discuss that the root cause for many of these common failure points is really the ability to lead projects, not just manage them…”

180 View – The article identifies missing leadership as the key reason for project failure and discusses the competencies required by leadership – 1) Leading courageously, 2) Influencing others, and 3) Acting with resilience. We agree that leadership is vital but we are not convinced that project management leadership is the primary driver of success or failure. Project managers are often middle management types or external consultants. The real power is usually found elsewhere. So it is vital that management demonstrate clearly their support of the project manager. The project manager may also not be able to select all the project team members or the amount of time they can spend on the project.

April 13, 2009 from Toolbox for IT – “…This is the situation where I find myself. I have a finite budget to drive this project. It would be good if I knew that I could complete the project before I ran out of money. Conversely, it would be good if I knew that I need more, and should either cancel the project or start setting expectations about the funding request I’ll be making in the future…”

180 View – At the beginning of any project, you don’t know all there is to know. Project managers would like to wait until they know exactly the scope of work, but they can’t do that. Management is not about to give the go-ahead without understanding scope, timing and costs. The people who will be involved in the project need to know that they have enough availability to get the job done in time. The article discusses a methodology that might work for you.