180 View – The article also discusses three qualities in an excellent project manager one of them being the ability to synthesize. The author, Lisa Anderson, has certainly demonstrated her synthesizing skills by being able to come up with the three qualities.

“One year ago my company embarked on an enterprise-wide implementation, selecting an ERP system and a suite of software to address our primary business functions. This decision was not made lightly. Lestornia Lighting is a $120 million manufacturer of commercial and industrial lighting fixtures and components (e.g., sockets, lampholders, wiring harnesses, reflectors). We’ve grown incrementally over the past two decades, and our business practices and processes — and the information technology (IT) that supports them — has grown piece by piece as well. I finally concluded that the Frankenstein IT infrastructure we had cobbled together needed to be destroyed. Now I greatly regret my decision…”

Literally from the outset of our enterprise implementation, the scope of functionality, customizations, and departments and personnel engaged in the effort have spread like wildfire. Lestornia expected to be operating with our new systems six months ago; now we cannot get a projected date for when we will hit the switch. The escalation of costs specific to software licensing and the implementation have blown beyond anything I’d ever imagined. And with the infectious spread of applications and department-specific functionality and customization, our training and maintenance costs are doubling by the day.

I swear that every person in the company is working on this system and software implementation in some way or another, and no one is focused on making lighting products or focused on our customers. I am afraid that this project will, quite simply, kill Lestornia before we ever see a dime of return from our investment. How can we subdue the new monster we’ve created?”

180 View – Although the problem is hypothetical, most people have heard of similar nightmares. Our opinion is that the risks of these problems occurring have been significantly reduced, but not eliminated. There are many ways to reduce the risks but the one that seems most relevant in this case is lack of scope and requirements definition prior to the selection of the new system.

1. Scope creep
2. Asking customers what they want
3. Inability to adapt to change
4. Failure to communicate effectively
5. Failure to communicate frequently
6. Unwieldy documents and too much information
7. Hidden project artifacts
8. Ambiguous requirements
9. Failure to measure and assess requirements processes
10. Isolating your requirements

180 View – Although the article was written for getting requirements for software development, it also applies to getting requirements for a software selection project. The key difference between requirements definition in software development and software selection is in the level of detail.

One would not expect “asking customers what they want” to be a trap. The article claims that “customers tend to talk about features, not what they truly need. The truth is that people often don’t know what they want.” The article says the solution lies in asking customers why they need a particular solution. I agree with the problem but not the solution. It would be better to ask the customer to describe their existing business process and its problems. In this way, the customer exposes the strengths and weaknesses of the existing system, and the business analyst can suggest alternative ways to solve the problems. The business analyst should know what is possible in software development and what is possible in existing systems but also needs to understand the business impact of a particular problem. There is no point in creating or implementing an expensive solution to a problem that causes a few minutes to be wasted a week for one person even though the customer finds it annoying.

The article’s list is

1. Inspires a Shared Vision
2. A Good Communicator
3. Integrity
4. Enthusiasm
5. Empathy
6. Competence
7. Ability to Delegate Tasks
8. Cool Under Pressure
9. Team-Building Skills
10. Problem Solving Skills

and you will find a description of the qualities in the article.

180 View – I also get the same question from our clients as to what makes a good project manager. But our answer is not the same as the article. Perhaps the reason for this is that our clients are usually asking about project managers for an ERP implementation. My advice published in October 2008 for CAmagazine was “a good project manager listens well, sees the big picture, is also detail-oriented and can communicate effectively. The project manager is highly motivated to succeed and enjoys challenges. Finally, the project manager has the backing of senior management and the respect of his or her peers. For an ERP project, the project manager should also know the business, and the scope of an ERP project typically includes at least financials and operations. It’s not easy to find one person who combines the right attitude and aptitude with business knowledge of both financials and operations. And to make matters even worse, the project manager will be very busy with the ERP project and unable to work on other tasks. I recommend picking the person who comes closest to meeting all the attributes, which actually leads to one more characteristic – the ability to delegate. Take your time on this decision, as the project manager can make a big difference in the success of the ERP project.”

It is very tough to find a project manager who not only has the business experience, but also skills, aptitude and experience in project management. My advice is that it is more important for the project manager or project lead to have the right aptitude and knowledge of business. Pure project management skills can be outsourced.

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

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.

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

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.

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’

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’!

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.

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.

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.