Project Management Blog

1. Poor planning:
Who are your IT managers and do they get enough opportunity to plan or under pressure from senior management they tend to think planning as a waste of time because they believe that time is better spent doing something rather than planning. Do you involve your project team in planning? Do they have the skills and experience to make complete plans? Or you always ask them to implement the solution. These are fundamental questions that need to be answered first.

2. Unclear goals and objectives:
Many IT projects are elaborated progressively and in these scenarios project managers rely on rolling wave planning. As a result, the goal of a project may be only partially clear due to a poor requirement gathering in the definition stage of the project. In such case, the scope and schedule developed by project managers cannot possibly be accurate because their objectives are unclear. Defining clear requirements for a project can take time and lots of communication.

3. Poor Stakeholder Management:
Project stakeholders’ interests may be positively or negatively impacted by the project and that is why stakeholders’ influence on the project is the most important thing to consider. Stakeholders who are found later will make changes and could cause delays. Any change that is made later is harder to integrate and is much more costly.

4. Scope creep and Feature creep due to objectives changing during the project :
Uncontrolled and unexpected changes in user /stakeholder expectations and requirements as a project progress always negatively impact a project. This is known as scope creep. Many times new features are added to the project with a wrong assumption that one small feature will add nothing to cost or schedule. This unplanned addition is called feature creep.

5. Unrealistic time or resource estimates:
Many times project managers make costly mistakes while estimating time or resources. One common mistake is made during the creation of the Work Breakdown Structure. Often it is assumed that the time on task equals duration. Project managers estimate the time on task is the time the task will take to complete. How about interruptions? Some may be known and some may be unknown. Do project managers anticipate interruptions? In reality duration is the time the task actually takes to complete including interruptions.
Another common problem is using linear approximation when estimating the schedule For example, if you double the number of developers, you can cut the project time in half. In reality, doubling the number of developers produces a non-linear result.

6. Improper delegation of task and responsibilities:
Many times project managers fail to delegate tasks and responsibilities to the team in such a way that they should fit team members' job descriptions. When team members are asked to work outside their specialization (often as added responsibilities), they not only go through a learning curve but also tend to lose focus on the project objectives. This always results in confusion among the team members and eventually cost and time overruns.

7. Lack of executive support and user involvement:
IT managers face many difficulties in managing projects and the lack of executive support and user involvement are the two main reasons of IT project failures. Many times IT project managers work as project coordinators or project expediters and without executive support they cannot personally make and enforce decisions. The second reason is user involvement and often the project planners fail to plan human solutions to the very human users that the product is proposed to serve.
8. Failure to communicate and act as a team:

Projects sometimes fail due to improper communication. Many large IT projects are so complex that these projects always require large amount of analysis and work. The project teams are busy doing the analysis, creating WBS, time estimation etc. and project managers do not communicate progress regularly because they believe that progress will not be seen by the executive management or they fear of improper reporting.

9. Lack of proper risk management:
Another potential cause for project failure is the IT managers’ inability to categorize all the risks qualitatively and quantitatively and implement corrective measures.

10. Inappropriate skills:
The rapid changes of the technology-driven business environment and the constant changes of technology make it hard to predict skills the IT department will be needed.
Almost all large IT projects require a diverse range of skills. Many teams lack the breadth, and depth they require. Also dearth of qualified people in the labor market and high attrition rate of the industry add many problems to the projects. Often, projects mangers spend substantial amount of their time in recruitment related activities.

We’re often asked “Why are templates so valuable” so we thought we’d answer the question in this Article. There are 5 reasons why managers and teams find templates so useful. They are as follows:

They save you time

On every new project, you have to fill-in documents to plan, track and report on the status of your project. The process of filling in documents, takes time. Especially when many of the documents are a one-off.

By using templates, you can save time completing project documents. Well written templates should already be pre-formatted with all of the sections, tables, charts and forms you need to fill-in. This way, you can avoid having to spend time formatting your documents and purely focus on filling them in. On average, most people save 25% of their time completing project documents, by using properly formatted project templates.

They give you direction

The first step most people go through when they know they have to create a project document, is to search the internet or their file folder to work out what it is that needs to be included. But if you use good quality templates, then they will direct you through the steps you need to take to create each project document. Direction is important because if you go down the wrong track with your document, your project will be at risk. Proper project templates will keep you headed in the right direction, by making sure you complete the right content at the right time.

They make it easier

In short, a good quality template will make the task of creating a project document, as easy as 1-2-3. You don’t have to stress about what need to go in your document, how to format it or how to write it up. The template will tell you what information needs to be entered and where. And it should include practical examples to help you along the way. This makes your job easy.

They boost your quality

It makes sense that if you’re completing a high quality template, that you will generate high quality documentation. If you want to generate documents of the quality that professional project management consultants generate, then use project templates that match this level of quality. By using top quality templates to deliver top quality documents, you will boost your project success.

They give you confidence

Have you ever been asked to write a document that you’re unfamiliar with or have never written before? If so, then by using a template, you will have the document layout, tables, charts and completion instructions at your finger tips. All you need to do is to fill-in the gaps. By using templates to complete new documents, you will gain a higher level of confidence in your work, helping you to excel.

Jason Westland has been in the project management industry for over 15 years, manageing multimillion doller projects. Jason now owns a company who specialise in project management templates and can be found at http://www.method123.com

1. The ultimate long-term relationship: Secure and maintain executive management support:
To gain and sustain project momentum, executives must support the automation of project and portfolio management processes that span multiple business units.

• Enterprise projects cross organizational boundaries and touch multiple levels within each business unit. To keep support from end users, it is critical to understand the value of working with the project and portfolio management (PPM) system. Executive support and reliance on data from PPM systems quickly and clearly communicates business value.
• The most successful customers invariably have had strong C-Level support and engagement. Conversely, those that do not have such support often experience implementations that tend to falter or take longer time to deliver value.

2. See the forest and the trees: Gain visibility into the entire corporate project portfolio
Real-time visibility helps you understand how project investments are aligned with corporate goals.
• Knowing which projects will add value to the business -- and which will not -- is a quick way to achieve rapid return on investment. The Gantry Group 2008 Benchmark Study of PPM users demonstrated that in just one year, firms that canceled non-strategic projects saved nearly eight percent of their annual IT budget.
• Visibility into the entire portfolio helps show project dependencies and adapts projects and resources when business conditions change. This ultimately keeps projects on time and on budget.

3. Standards are your friend: Implement and automate standard project methodologies
If your organization is going to rely on the information gathered by a PPM system, then likewise, you need to ensure that the data is reliable and credible.
• Implementing standard project methodologies will provide much needed consistency to data capture, aggregation and reporting.
• You can greatly increase project manager productivity by implementing standard project management practices across the organization. Doing so eliminates the need to manually aggregate information from multiple, disparate sources. The Gantry Group 2008 Benchmark Study of PPM users revealed that automating standard project and portfolio management practices decreased time spent generating status reports by more than 30 percent after just one year.

4. Keep it simple
Don’t over engineer your processes!
• Focus on automating process areas that will deliver the greatest initial value. Stay committed to process simplicity – because this focus will make it easier to implement and adopt a PPM system.
• You need early wins. If you over engineer your processes or try to push the organization past its maturity level, users will abandon. Again, stick to automating a process that will fix a known organizational pain point – in as few steps as possible.

5. Rise and shine: Measure and communicate (early and often)
Set benchmarks that will show your business executives that the solution is delivering benefits. Remember: you cannot over-communicate success in the early adoption stages.
• Determine a metric you’d like to improve. For example, pick improved project timeliness or increased project manager productivity – and make a point of capturing information so that you can report on it to management at intervals that make sense for you.
• Establish regular communications with your management team, using real-time reports and dashboards. Use the information as the basis for decision-making. Doing so will help build your credibility, while keeping people informed and discussions more focused on facts and less on emotion.

Project Management is perhaps one of the most fiercely debated and grossly misunderstood disciplines in the software field currently, hence let me throw in a disclaimer first: if you are a small team of experts and/or people well-known to each other (e.g., have worked together as a team earlier), and situated in a collocated fashion, doing a lot of ‘creative work’ that can’t be very ‘accurately’ scoped, let alone managed; you probably will find ideas of formal project management a huge overkill (on time, effort, money and might even seem to stifle creativity), and you might be better off considering ‘lightweight’ methods like Agile Project Management / Scrum in the context of software development (well, nothing stops you from deploying pieces of Agile / Scrum in a non-software context – it is based on common sense after all). Small projects, small teams can afford to define a process that exploits the tailwind:

- A small and collocated team means more direct interaction among team members and lesser management overheads in formalizing project communication (e.g., project status reporting, team meetings, etc.). This reduces the time it takes to collate, transmit and share important project information and also decreases the possibility of information distortion or confusion. A small team means there is high signal to noise ratio in team communications, is also leads to a better utilization of time spent in transmissing, receiving or digesting communication. Further, to schedule any event, one can always convene impromptu meetings around a whiteboard or around the coffee table without worrying about people’s already double-booked calendars or finding a place large enough to fit the team for the next meeting, and so on.

- Having a group of experts means there is low(er) need for managerial supervision and people are generally ‘hand-picked’ for their knowledge, skills and abilities that could typically be ‘mutually exclusive, collectively exhaustive’. This ensures tight interdepency and very high mutual respect among team members. There is lesser ‘competition’ among team members and everyone knows that “united we stand, divided we fall” which fosters teambuilding.

- For a small project, a large swing in any of the project constraints (time, cost, scope) could seriously and irretrievably impact the project in a downward spiral. If the work is new to the team, it could spell bigger trouble, especially if there is no way to do mid-course corrections. Executing projects in an iterative fashion helps shorten the feedback loop and give a chance to make necessary corrections to improve its ability to stay on-course and eventually hit the target. Additionally, if there is a customer involvement on these short iterations, the quality and value of these feedbacks could improve substantially lest any decisions are made that are hard to change if required.

However, if your project is anything more than a handful of people, takes more than a few months and entails issues like external dependencies with multiple vendors and ISVs (Independent Software Vendors), substantial technical and managerial risks, subcontracting / co-development, etc., you probably might improve chances of success using a formal project management methodology like PMBoK or PRINCE2 than without it. Agilists will argue and disagree with me that Agile / Scrum is not suited for large projects, but if you are new to Agile as well as to large projects, you might want to consider all options and associated risks – don’t believe in what worked for others, it might or might not work for you (remember the golden rule – we are all different), and your company might have a different set of constraints and tolerance to performance.

The size, complexity, criticality, and risk profile of a project, and organizational appetite for project risk and uncertainty, and organizational culture would generally determine the level and need of management control required, and hence one must always right-size the project management methodology based on the context. Both, PMBoK / PRINCE2 and Agile methods evolved in response to challenges seen in executing projects successfully. While PMBoK / PRINCE2 took the approach that projects most often failed due to lack right levels of management oversight, planning, execution and control; Agillists felt the key reason was the fundamental nature of software being a ‘wicked problem‘ that just could not be managed using an obsolete waterfall model of developing software - it needed a better way to develop software in short iterations with very close-knit self-managed teams.

Without getting my loyalties needlessly divided betwen the two of these approaches, I believe there are merits in both the thoughts. I refuse to believe that any non-trivial project can be managed by piecemeal iterations that give no commitment whatsoever on the overall project performance, nor give any method to assess if the overall project is indeed on the right track (so, even if first few iterations are achieving the desired ‘veolcity’, what is the guarantee that subsequent iterations will also move at the same pace?). On the other hand, doing an iterative development is highly intiutive and very effective way to learn from past experiences to plan next steps, especilly on any non-routine project that is full of unknowns and assumptions. To me, these represent ‘mix-and-match’ ideas that one should pick up and apply wherever required, without getting baptized to the school of thought. I find most process wars have taken the disproportionate dimensions of falling just short of religious wars – you have to belong to one of the camps, and must talk evil about the other camp to be seen as a law-abiding corporate citizen of that camp. In life, we borrow ideas around us – our housing society, professional volunteer society we volunteer for, our kids playground, gardening, home improvement, nature, science, religion, other cultures…without necessarily converting to another faith or religion or society just because we like an idea that we want to borrow. So why should that be required in project management methods ???

I think this process war will be won by pragmatics. Those who take a position on extreme ends of the continuum and insist on always applying a particular style as the panacea might be in for a complete surprise because no two problems were created equal. A prudent approach is to evaluate all options and then decide which is the best response to a problem, as opposed to blindly follow a project management approach ‘religiously’.

Do you follow your project management aproach ‘religiously’ ?

[From my blog Manage Well, http://managewell.net]

I've worked in marketing and product development for a biotech startup for about three years. I have no formal training in project management and it hasn't been mentioned in my job description, but I've been working in a project management capacity for most of my time here. Shortly after I came on board, we were forced to do a major overhaul of our flagship product. Suddenly I went from writing copy and placing ads to sourcing vendors, developing prototypes and creating entire new product development plans. Talk about on-the-job training. I was a project manager and I didn’t even realize it. I came to this realization as I started reviewing the requirements for the Project Management certification exam. I have some friends with IT certifications, and they recommended this to me. Listening to their experiences, I thought I could go through some sort of training, take the project management exam and have the certification quickly. It's not that easy. In addition to formalized training, you also need experience. Getting this certification has the same kind of catch-22 as getting a job. Fortunately for me, I think I have the difficult part under my belt already. It seems easier to accumulate the 30 hours of training for the exam than it is to get the hours of experience. I have a bachelor’s degree, so the requirements aren’t as stiff, so I’ve got that going for me (which is nice).

My decision is mostly made up, but I'm trying to find out what the consensus is. Is the PMP exam worth it? Should I consider training for other project management certifications, like Project+ or this Project Management with Microsoft Project certification exam I've read about (Microsoft Project seems cool, but is it really useful on the job.) I want to add some formal credentials and training to the sweat equity I've already earned. What does everyone think? I’ve never been much of a blogger, but I’ll be sure to check back for responses and post more stuff.

In the following posts I’ll define the term “Internal projects” and will show that they are essential for any IT department.

Despite the fact that there are managers out there, that understand the value of inner projects and the fact that these project already exist, too many IT departments still fail to understand how important they are. Thus, my task is to offer another point of view of this subject, which will hopefully help more IT managers see the light.

So let’s start by defining the term – “Internal project”

Internal project is a development project which output is a tool or a system that only serves the IT department. The project is financed solely from the IT budget and the system does not generate any direct revenues.

At first look it doesn’t look like much of an offer. Give me your budget and give me your time any in return I’ll give you a tool or system that generates no revenues. No wonder a lot of managers refuse to this strange offer.

Nevertheless, strange as it may look, any IT manager must accept this offer.

So as I said before…In the next posts I’ll show why are the Internal Projects so important and how they should be implemented

Asaf Gilad

It is imperative to understand the overall Business goals of an Organization while it comes to executing Projects.

In today’s world of rapid change, often Management has to fine tune the methods and roadmap to reaching Business Goals. Eventually this frequent one degree shift impacts the whole Organization. However these changes are not trickled down to the floor where the work gets done - as a result the projects start drifting away from the Project goals and the PMO start panicking....
The ongoing economic downturn has forced Organizations to live on split second decision. Probably it’s a new way of governing Corporations and the project Teams have to learn it fast to cope with it.

I think the PMO should work very closely with the Management and any and every shift and turn should be propagated to the Team members with its impacts. This open communication helps to rebuild the lost confidence, keeps the project in focus and finally accomplish Corporate goals.

Overview: Risk management is a key, if under-appreciated, part of project management. Managing things that you’ve mapped out thoroughly and understand in detail is challenging at times, a science in its own right. However, a knack for managing unknowns elevates your work to the level of art.

Every professional Project Manager understands the triple constraints of scope, schedule and budget. We also understand that everything affects everything else. Of course there are other constraints such as quality, customer satisfaction and so on that we also have to consider. External constraints impact your projects such in the form of weather, labor conditions and even legal requirements. Dealing with these known constraints is a big part of the planning effort and putting those different parts into a coherent and effective whole is every bit as much an art as composing a symphony.

Now… imagine performing your grand opus in the middle of a desert in Dubai or in the middle of retooling for a manufacturing plant. Imagine performing your symphony without a dropped note while changing out the IT infrastructure for the banking industry during a financial crisis. You no longer have quite the same opus.

You have a series of choices to make to deal with the unknowns you’ll face. Each choice will affect other parts of your project. Chances are good that your project will spin off into chaos. A very large part of all projects do fail in at least one of the triple constraints.

To stretch the musical metaphor just a bit further, imagine your project not so much as a symphony, with every note placed just so in the idealized setting of the concert hall… imagine it as jazz.

Risk management is the tool set and approach that allows you to work within the chaos to produce beautiful music, even if you arrive at the end by a different route every time you play.

Framework: First, let me sell you a little on why risk management is worth the extra effort. Then let’s look at how you can promote risk management to your stakeholders and use it most effectively. Finally, some thoughts about risk management in general to help put everything into perspective.

Somewhere on the Internet is a web site devoted to “The 2 Rules”. It contains a long list of heuristics, rules of thumb, for hundreds of professions. For example, boxing has the following two rules:
1. Hit the other guy
2. Don’t get hit

For amateur project managers, the two rules might be: 1. Things go wrong
2. See rule 1

For a professional PM with some experience:
1. Things go wrong
2. Deal with it

For a PM who really understands Risk Management…
1. Things go wrong
2. Take advantage of it

True, doing a credible job at risk management takes extra time and effort, along with the active participation of the project team – things which are all usually in short supply. However, it’s one of the few parts of project management, aside from the work breakdown structure itself, where you get multiple benefits for a single activity.

Here are some things to consider about Risk Management. You get more accurate estimates, sometimes lower than originally planned but almost always more accurate. You get the Work Breakdown Structure clearly understood, communicated and even critiqued by all the key project team members. You have actively looked for possible problems and also possible opportunities that will help the project. You project team not only understands what needs to be done, it now understands how problems in one area affect the other areas. You get the chance early in the project, when changes cost the least, to identify and fix potential issues.

If those things helped convince you of the value of Risk Management, consider these things when you try to advocate for it:

When “Things go wrong”, you have a plan to deal with them in the most effective manner possible, as early as possible.

When things go right, you get the choice of going to your stakeholders and returning reserves from the project budget or of bringing in the project further under budget.

If you have planned well, you may have the chance to take advantage of unexpected opportunities. Not all risks are negative risks. For example, because of risk reserves set aside for price fluctuations in energy, when fuel prices dropped, you were able to buy all your asphalt paving and asphalt based roofing materials at a steep discount. When the prices rose again, you’ already locked in at the lower price.

As any professional PM will know, when things go wrong it’s ultimately your job to deal with it. If your planning has been effective and if you have been successful in building good contingency plans, you won’t be left wondering what to do next in the event of problems.

General Thoughts On Risk Management and Project Management --

It seems to me that it’s a lot easier on the ego to learn from the mistakes other people make but it seems to stay with you better when you do it yourself.

Building on my earlier musical metaphor, give some thought to how a jazz combo goes about producing an improvisational piece that’s more inspired than the original. Jazz is anything but spontaneous; a good musician has practiced for years and truly understands the territory. The group practices and rehearses together. There is a solid framework underpinning the music that never goes away. A riff may go far from the original tune, but at some point always returns to the original direction. The best jazz musicians work well together; know what to expect from each other and play to make each other sound better. While jazz is being produced, nobody just “phones it in”. Everyone is fully engaged and paying attention. See any parallels to what a great project team should look like?

We can draw Risk Management lessons from the armed services. I’m referring to combat of course, but specifically I’m thinking about damage control. In combat, THINGS GO WRONG. That’s what combat is. If you don’t have a plan, have it understood by everyone, have it well rehearsed and prepared in advance, people die. People you care about die.

Some general principles in combat risk management that apply to all risk management:
1. Have a plan
2. Make certain it is flexible
3. Keep it simple (at least simple to execute for the guy on the front line)
4. Make sure it’s understood by everyone
5. Practice, rehearse and think it through in advance.
6. Always have reserves in place
7. Be prepared for the worst case
8. Be prepared to jump on opportunities
9. Have a back-up plan
10. Have a fall back position prepared
11. Someone always fails to get the word, be ready for that.
12. Always guard your supply lines

Sometimes, Risk Management can be daunting. It’s helpful to have templates and checklists to help think through and brainstorm about things that can go off track.

Use a Risk Register to track risks and the trigger points when those risks must be dealt with. It’s a great way to keep from getting blindsided.

When brainstorming, tell the team that you will make several passes through the list of risks to get a better picture. Try to go through at least one pass that’s just “silly stuff” like asteroid collisions to get the team to loosen.

Realize that all risks get written down but only risks considered to be above the tolerance threshold are going to actually require follow-up. Others will only need to be monitored.

Try throwing out lists of categories, like “Manpower”, “Money”, “Management”, etc. to give people a starting point to drill down and capture general risks. Try “Politics”, “Processes”, “Payment” or the more familiar Initiation, Planning, Execution, Management, Closing cycle. See if you can get two or three risks from every category.Be sure to work through risks that are specific to each work package in the Work Breakdown Structure.

Once you’ve captured a list of risks that you think is comprehensive, try making a pass through it to see if you can identify positive risks, (opportunities).
It’s rare that a problem can’t be turned to some advantage.

Once you have your risk register populated, it’s time to evaluate, quantify and plan for contingencies. Be certain you have a good understanding of your stakeholder risk tolerance levels and be sure to communicate with them regarding the way you’ll set your risk tolerance thresholds. You may want to consider dual risk tolerance thresholds for large projects. A lower one where a trigger for action is defined and an owner assigned to monitor the risk, then an upper tolerance threshold beyond which contingency plans must be developed.

For smaller projects, for risk of low impact and low likelihood, it’s probably a safe bet to make the assumption that one or two will occur (add into the reserves) and ignore the rest.

Getting accurate estimates for the work needed to deal with risks will allow your overall budget estimate to be more accurate. The reserve planning for both time and budget can be used to communicate with the project team why it’s not a good idea to pad estimates. As you develop the risk estimates, you have the opportunity to explain the purposes of the risk reserves and management reserves.

Risks with very high probabilities, 90% or above, are equivalent to issues or events. You might as well deal with them as if they have already occurred. If you do get lucky and the 90% probability doesn’t happen, you’ll have taken a calculated risk, pun intended, that in this case simply didn’t pay off. Think of it as buying insurance. If you had failed to act and not committed resources when the risk became reality, you’d have been much worse off.

Summary --- Risk Management tools and techniques and the team’s awareness of the need to accommodate risk allow you the ability to remain relatively calm while dealing with chaos. Risk Management allows you the freedom to plan for the truly unexpected because you don’t have to waste time dealing with those risks that could be reasonably expected. You may even get the chance to grab onto opportunities you’d never see or be able to capitalize upon without this preparation. You are the conductor in the symphony of your projects. Risk Management might just be the grace note you should consider emphasizing in your next composition.