Stop Scope Creep from running away with your Project

Duncan Haughey for Projectsmart, discusses causes and solutions to prevent scope creep from ruining your project.

Scope creep is one of the most common reasons projects run over budget and deliver late. Often done with the best intentions, changes to scope during a project are a negative event best avoided.

Most project managers have experienced a case where the customer asks for something outside the scope agreed and expects it included at no extra cost. In fact, they're probably acting as if it's always been in scope.

Defining the boundaries of a project is difficult, but without a clear definition you're heading for problems.


To summarise, ensure you set expectations correctly at the beginning of a project, working closely with the users to define clearly what is in and out of scope. Record it in the project initiation document. However, don't assume the customer will read and understand this document. Spend time with the customer to walk them through it and ensure they understand and agree the scope. Don't continue without a firm agreement.

Often it's not possible to avoid increasing scope during a project, especially if there is a sound business reason to do so. However, it must be managed properly. Design a change control process to ensure all changes are properly documented, considered, approved and resourced. Note: Where budget and time are increased with scope, the change is not usually considered scope creep.

Alternatively, you may wish to prevent changes being added piecemeal during the project and may decide to document them for a later phase. This allows the agreed phase to be delivered on time and budget, and the changes managed and resourced separately.

If you consider that only 32% ¹ of all projects fully succeed; then you're better-off spending your time delivering the requirements agreed at the beginning of the project, and avoiding gold plating.

Scope creep causes many project failures; by taking a few simple measures you can make sure it doesn't affect your projects.

Read the full article at:
Stop-scope-creep-running-away-with-your-project.html

Can Agile work with CRM?

One challenge is wasting time treating each little sequential task (e.g. in Salesforce setting up validation rules, roles, field level security) as a separate story, requiring MORE time documenting things in a tool like Pivotal Tracker, then actually performing the tasks themselves. Because there are many sequential tasks with CRM. So many that documenting as individual stories takes an excessive amount of time, thus hindering rather than helping progress. What happens is when you apply true Agile, I’m finding, is that organizations STILL get hung up in too much PROCESS and DOCUMENTATION especially with new Agile teams, which almost all Salesforce CRM teams are. And what does the Manifesto say about a little concept about less documenting, more deliverables, less process, more collaboration, don’t get hung up on tools??? Right??? It’s important to stick to the principles we all live by, but with CRM, allow for flexibility in order to keep things moving effectively.

Read this excellent article by Tommy Ball for AgileScout:
Agile-and-CRM/

Project Failure: Cobb's Paradox

Cobb’s Paradox states, “We know why projects fail; we know how to prevent their failure – so why do they still fail?”. PMI has recently published its latest Pulse of the Profession survey which shows some improvements on the 2008 and 2006 results but not much. Nearly half the projects surveyed in 2010 still failed to meet time and cost targets.

However, the PMI survey did highlight a stark difference between high performing organizations with a better than 80% success rate, and low performing organizations with a greater than 40% fail rate. And, the survey also clearly showed the processes typically used by the high performing organizations (and ignored by low performing organizations) are straightforward to implement and use; they include:

• Using standardized project management processes.
• Establishing a process to mature project, program and portfolio management practices.
• Using a process to increase project management competency.
• Employing qualified project management

So, given the tools are available, the knowledge is available, and the value has been consistently demonstrated; why are organizations still prepared to squander $millions on failed projects rather than investing a fraction of that amount in simple systems that can significantly improve the value they deliver to their stakeholders?

Read full article by Lynda Bourne for PM Hut:
Project-failure-cobbs-paradox

Project Estimation: Two Conflicting Trends

In a number of organizations I have noticed two conflicting trends:

• Organizations want business cases produced earlier (to prevent wastage of funds)
• Organizations want increased estimation accuracy – typically ± 10%.

While the objectives are totally understandable, they are unrealistic.

If you insist on a business case too early in the project life-cycle you incur a high level of uncertainty — there are many things that you don’t know or don’t know well enough to accurately estimate. Often business cases are generated based on “high level requirements” – but, as we all know, the devil is in the detail and when the ‘detailed requirements’ are later defined they will often blow the budget.

We need to remember what we’re trying to achieve – ie not waste money, not allocate money to poor projects (however you want to define that) and not have big cost blow-outs. Bringing the business case forward and insisting on greater accuracy will not achieve this.
Instead, what you need to do is…

1. Recognize that there are ’sunk’ funds, ‘at risk’ funds and ‘total’ funds.
   • Sunk funds are the expenditure to date – this money has gone whatever happens in the future. It may be painful, but it is not recoverable.
   • At risk funds are the expenditure that you’ll lose if you invest in the next stage and then cancel the project. While you want to minimize ‘at risk’ funds, you also want to invest enough to see if the project will be valuable and viable on a reliable basis.
     
   • Total funds are the total expenditure to the end of the project and are only at risk when they’re allocated and then spent. However great the total funds are, they are not at risk until you put them at risk. Better to spend, say, $5m determining the true value and cost of a project than, say, $500K to generate a baseless business case that later explodes in cost or implodes in value.
2. Recognize that the level of uncertainty is high until the requirements are known and the design agreed. Up until then the level of uncertainty is certainly above 10%.
   The progressive questions a project needs to answer (as cheaply as practical) are:
   
   1. Is the idea/concept relevant?
   2. Is the project likely to be valuable and viable?
   3. Can we afford it?
   4. Can we deliver it?
   5. Do we have the capacity to deliver it?
   6. Is this the best use of our resources now?
   As soon as any question is failed the project should be stopped and any remaining funding reallocated to other initiatives. The early evaluation process should, therefore, be focused on answering these six questions at minimum cost rather than insisting on early but unrealistic certainty.
   
3. Ruthlessly review projects/ideas/initiatives to see how they are faring against the six questions – and stopping any that fail as quickly as possible.
   Along the way there will still be areas where you won’t know the answer yet – and this then needs to become the focus of the next stage of the project.

By the time you get to the final business case stage you should have no unknowns. Then you can have an estimate ± 10% and rely on it.
Accuracy demands in the face of reality is not a useful approach.

Article by Jed Simms for PM Hut.

Rework will Happen

Excellent article by Michael Greer for PM Hut:

How to Design a Project with Rework Opportunities Built In

The following process will guide you through the process of designing a project plan with plenty of rework built in.

1. Assemble all project documentation you’ve created so far, including the stakeholder-approved Project Scope Statement, WBS (work breakdown structure), technical specifications, proposals, and so on.
2. Assemble the core project team and as many stakeholders as possible.
   
3. Conduct a brainstorming session in which the core project team and stakeholders do the following:
   
   1. Examine each specific deliverable that must be created. (Refer to your WBS… )
   2. List the specific tasks that must be performed to cause that deliverable to evolve from rough idea to finished product. (Use yellow stickies, flip charts, white boards, mind mapping methodology and other tools of brainstorming you like.)
      
   3. Incorporate plenty of opportunities for stakeholders to review work products in small increments, as they are evolving. So, for example, if you are writing a report, don’t wait until you’re finished to share it with reviewers. Instead, share (and get feedback and make revisions to) an outline first and then a rough draft, before you spend your time finalizing and polishing the report. Specifically, insert as many “create, share, feedback, revise” cycles into your task list as possible. This will help prevent unplanned rework (and blown schedules from having stakeholders reject your deliverables!) by building opportunities for review and revision into your plan.
      
   4. Combine and organize the list of tasks/activities into broad collections of related tasks or phases.
      
   5. Create a network diagram (flow chart) showing the sequence and flow of all project tasks, activities, and phases. (See Sample Network Diagram, below.)
4. Polish and finalize the network diagram and task list.
   
5. Circulate the network diagram and task list to appropriate stakeholders/sponsor and get formal approval (i.e., sign-off). 

Never Build More Than You Want to Revise

The spirit of the diagram above is this: Never build more than you want to spend time revising. That is, don’t risk hours of work in the “wrong” direction. Get feedback early and make adjustments early, then repeat — a little at a time, in small increments.

Read the full article at: 

Rework-will-happen

Top 10 Procurement Risks - Tender Preparation

Responding to RFTs (requests for tenders) can be risky, given that your tender response is a legal offer and you may be bound to the terms within it, if the client accepts it. Responding to a complex tender can also be very time-consuming, tying up substantial company resources for significant periods of time.

Top 10 risks

Below is a list of potential risks that should be assessed when responding to Requests for Quote or Tenders. These risks are generally the same as those you would identify for any building and construction project:

1. What constitutes a breach of contract and what is the resultant impact. Will a breach trigger termination, or will it require make good or rectification at your own cost? Can you terminate the contract or can it only be done by the client?
2. Delays caused by circumstances outside the builder’s control, such as; delivery delays that delay project completion, subsequent delays in progress payments, labor shortages, weather. Are you liable for any delays and what is the impact of this liability?
   
3. Exposure through clauses that work against the building organization, such as clauses that hold the builder responsible for circumstances outside their control.
   
4. Disputes over payments, either payments from the client to your organization or payment from your organization to subcontractors. Assess your cash flow to ensure that you can make payments to subcontractors even if you haven’t been paid by the client for a particular milestone.
   
5. Incorrect labor or materials costs, or miscalculations in any figures given. Have you added any budget or materials contingency?
   
6. Inappropriate funding levels and funding shortfalls for the project, resulting in a suspension or cancellation of the project or renegotiation of terms and conditions during the project.
   
7. Industrial disputes through misunderstandings on-site or through overt action.
   
8. Risk of default or non-performance of one or more of the key players, including the client, the builder and subcontractors.
   
9. Ignoring risk and failing to plan for it.
   
10. Positive risks. Risk is usually seen in a negative light, but some risks are positive and can be seen as an opportunity to enhance procurement objectives. These can include currency fluctuations and even proposed changes to legislation or regulations which could simplify compliance requirements and therefore reduce the overall cost of the contract.

Get more in this excellent article by Micheal L. Young for PM Hut.
Top-10-procurement-risks-tender-preparation

Nine Successful Keys to Delegation in Project Management

Are we doing to much delegation in project to an extent that we are far too relaxed, or are we not delegating enough for fear that the project may not meet deadlines? Fred Morgan addresses this in an article for PM Hut.

Successful delegation is crucial to successful project management. Many people involved as leaders in project management are, however, afraid of delegation. They fear that if they delegate, the work won’t be done properly. Deadlines won’t be met. They cannot trust collaboration and teamwork to others; they have to do most things themselves and directly oversee the rest.

It is the delegation itself that must be done properly, however. Project management depends upon delegation simply because of the law of the division of labor: one person or team focused on one or two specific task(s) is more efficient and more productive than one person trying to juggle multiple tasks. One cannot be all things to a project or a business. As far as successful collaboration and teamwork go, these elements take care of themselves from an “emergent properties” perspective once delegation is done properly. The more laissez-faire project management is, the better. That manager is best who manages least.

Read Morgan's full article at:
Nine-keys-to-successful-delegation-in-project-management

Chromebooks : Added Choice

Chromebooks has not yet seen the light of day and the doom-sayers are already having a field day. As with many new products that see the light of day, much time is spent to predict why it would be a failure. For eg. the iPhone 4 antennae debacle, Linux vs Microsoft vs Apple, Bing vs Google vs Yahoo etc. In all instances the underdogs has gained considerable marketshare and can boost on relative success.

Chromebooks offers a new dimension to computing and all realistic reasons may paint a grim future. But as with all articles that offer an opinion, the writer may have some bias. To assume that Google took on this venture on one assumption that everyone supposedly hates Microsoft is a bit far fetched. Google would not have been the number one brand, until recently surpassed by Apple, with a narrow-minded approach to new business. Chromebooks will be entering a huge market where product sales are driven by choice. The way it is priced, it is not too far fetched too assume that users will purchase it just for the sake of trying it out. It goes without saying that cloud computing does offer security challenges, but so does security in the conventional organization environment.

The challenge for Google lies herein, to drive the message that no additional hardware is needed to backup files, because documents will be saved in the cloud. Yes, hacking is a risk in the cloud, but organization server hacking is the order of the day too. No-one is immune to hacking. But are hackers really interested in personal files of the average user? I think not.

Facebook is an example of user trends to not protect their personal data by sharing personal data on personal pages and accepting third party applications that may divulge personal information. This trend suggests that the average user, whom will find the Chromebook affordable, talks about security, but does not entirely walk the talk. Wanting to be ahead of the pack and knowledgeable on the latest technology will be the winner at the end of the day. It is for that reason that I am giving the Chromebook a chance.

Broadband internet connectivity may offer increased opportunity for Chromebooks to compete in Singapore(96%), Hong Kong(99%), South Korea(97%), Switzerland(90%), Luxembourg(99%), Norway(84%), and Denmark(82%).

Chromebooks may surpass all expectations. I believe it will!

Please share your views.

My article is a response to an article by Mark Elgan for Computerworld:
Elgan_Why_Chromebooks_will_fail

Thoughts on Agile Planning

Great article on Agile Planning by Mike Cottmeyer for LeadingAgile, posted on Project File.

Agile Math

The basic math of team based agile is pretty simple. You can slice it several ways, but at the end of the day, one of these three basic formulas has to hold true. It’s all about time, cost, and scope… you get to decide which two constraints you want to lock, but then you have to derive the third.

1. backlog size / velocity = duration
2. duration * velocity = backlog size
3. backlog size / duration = velocity


I generally suggest that agile is all about fixing time and cost, and deriving scope… but it doesn’t have to be that way. Feel free to derive time based on a fixed backlog and known velocity. You can even derive a planning velocity based on fixed scope and time. This one is the most risky, so be prepared to measure, adjust, and negotiate as the plan unfolds.

Limiting WIP

But here is the rub… when a team has too much work to do, and not enough time to do it, there is a cognitive dissonance between the messages of agile and what they see on the ground. We can say all day long that the PO gets to decide the “what” and the team gets to decide “how” and “how much”… but if management is fixing all three variables, the team isn’t going to buy in.

Rushing the Backlog

Generally, here is what I ask from management out of the gate… give us three sprints to help the team come up with a backlog and establish a velocity, afterwards we’ll see what we have and decide how to proceed further. We’ll start by doing just enough backlog planning to identify a sprint or two worth of work, and get the team working to establish a velocity.

While the team begins work to establish their velocity, the PO aggressively moves to create the backlog. Almost never do I see a PO that can create a backlog all by themselves. Very often we need Product Managers, Architects, and Analysts to paint the complete picture. More often than not, I’ll ask these folks to work full time for as long as takes to get the backlog together.

I’ve got one PO team that has been at it 8 weeks just to get ahead of the team, and define the release. Initially the PO team is focused on feeding the teams high value, high risk stories… but as the backlog emerges we start rounding out the app. If all goes well, after several sprints we have a decent idea of what we have to build and the rate at which the team can complete the work.
At that point, we apply one of our three formulas, baseline the plan, and go.

Emergence or Convergence

How far ahead of the team you need to be largely depends on your business goals for the release. If you are highly uncertain about what you need to build, smaller backlogs are probably better, and the release planning process can be more nimble. Trying to predict stuff you just don’t know is waste. In this case, agile is helping support an emergent outcome.

Not all companies are going for an emergent outcome… some want stability and predictability. In these cases, the PO team needs to plan further ahead of the team and adjust as the product is developed. The better we know where we are going, and what it is going to take to get there, the further out we can plan the backlog, and the more certain we can be about outcomes. Here agile is supporting a convergent outcome with focus on risk reduction and predictability.

One of the biggest problems I see with teams new to agile, is that they act as if they are going for stability and predictability, when their product requires an emergent approach. Either requirements are not well understood or because of high technical risk or a ton of unknowns around how to implement. Either way, you have to act as if the project is emergent until you gain enough knowledge to establish a more predictable plan.

Not Knowing What You Don’t Know

I’ve met a few teams lately where everyone is new and unfamiliar with the product and the code base. How do you set a schedule in this environment? The short answer is… you don’t. It’s okay not to know, but it’s not okay not to know forever. In this case, you better have a plan to get it figured out fast… It’s not reasonable to indefinitely ask the business to invest with no strategy for getting to done.

Project Management Authority is Earned not Given

Leading by example generally earns respect and authority to the person that exercises it. This is by no means any different in project management as seen in the article by Dan Vickers and Kurt Finch for PM Hut.

For project managers, the support of their team is critical for completing projects successfully. Yet, a team’s respect cannot simply be assigned like a task. Acquiring and executing project authority with the support of a full project team demands careful and skilled execution.

Project leadership requires a humble yet assertive persona, capable of taking charge when needed and delegating authority wherever possible. A project manager must develop their own skills and lead with principles. Doing so will certainly encourage team loyalty. If a project manager simply presumes authority, they will never earn the backing of their team. This is an ongoing practice that should drive the way a project manager carries himself and shapes how he interacts with others.

Lead by Example

A project manager can’t just “talk the talk” but has to also “walk the walk”. If not, she will lose all credibility. In order for a project manager to earn their team’s respect, they must wholeheartedly support their own decisions and back them up with actions.

The most effective way to earn authority is to be a project leader that others want to follow. Be on time. Be kind and considerate. Be efficient with your tasks. Be organized. Be fair with others. Set an example for others to follow.
The project manager is a tricky position to navigate, yet just a few simple practices can enhance a project manager’s powers of persuasion and increase their influence enough to achieve tremendous things. A project manager should always remain cognizant of the fact that they aren’t the boss; they are a leader of a team that will be inspired to follow or struggle at every step along the way. The process will be made much easier by being kind, respectful, and benevolent in decision-making.

Read the full article:
Project-management-authority-is-earned-not-given

Tips and Tricks for Ubuntu after Installation

Click on the link below and enjoy the read.

Tips and Tricks for Ubuntu after Installation

Seven Deadly Project Manager Sins

In spite of an increased focus on competency in PM conferences, journals and online knowledge sources, organizations continue to experience project failures at the hands of incapable PMs.
Identifying common negative behaviors that can contribute to these failures might be the first step towards recovery:

1. Communication imbalance – communication consumes a significant percentage of a PM’s time so one would assume that this is a competency that even poor PMs would excel at. Unfortunately, some PMs treat knowledge & information like power – sharing it with those they wish to curry favor with, and leaving everyone else in the dark. Other PMs have a case of verbal “Montezuma’s revenge” – this is equally bad as stakeholders are unsure what information is critical and what is minutiae.
2. Neglecting stakeholders – Project Managers can get tunnel-vision by focusing purely on their direct customer or sponsor. While this individual might be the one signing deliverable acceptance forms and evaluating your performance, a good PM needs to practice 360 degree management – sponsor, stakeholders & team.
   
3. Inaccurate or incomplete project control books – It doesn’t matter how heavy or light your PM methodology is (or even if you organization doesn’t have one). There’s a basic set of project data that should be kept current so to facilitate project tracking, control, monitoring and (if you win the lottery) transition. Having an out-of-date schedule is worse than having no schedule at all – at least a stakeholder doesn’t draw any wrong conclusions from a non-existent schedule.
   
4. Ignoring conflict – Conflict is a natural occurrence on most projects but accidental PMs are often unused to managing interpersonal conflicts and might be tempted to ignore them in the hopes that the situation will resolve itself.
   
5. Jettisoning risk management – If a PM happens to be aware of good project management risk practices, they might not have the intestinal fortitude to “sell” the necessity for these practices to their sponsor, stakeholders or team. Under pressure to deliver, if they skip risk management, they’ll at least have the opportunity to improve their fire-fighting skills!
   
6. A blind focus on the triple constraint – While scope, schedule & cost constraints are important, a PM might ignore the fact that a project has to deliver business value to avoid “the operation was a success, but the patient died” syndrome. Poor PMs are less likely to ask questions such as “Is this deliverable necessary to the end result”, “Are we gold-plating” or “Is this project still of value to the organization”?
   
7. Poor assumptions management – Projects possess uncertainty and to try to reduce this uncertainty, we make assumptions. A good PM will log critical assumptions, share them with the overall project team, attempt to validate them proactively, and use them as one of the inputs into risk identification. A bad PM will forget the assumptions shortly after they were made…

By no means is this list exhaustive.

Article by Kiron D. Bondale for PM Hut.

Shuttleworth on Ubuntu 11.04 Linux and Unity

I installed to Ubuntu 11.4 Unity alongside 10.04, a couple of days ago. My first impression of the GNOME 3 interface was one of total dislike. I am willing to give it a couple of  days to grow on me.

Below is Mark Shuttleworth's take on Ubuntu 11.04:

Ubuntu 11.04 has been out for a few days now and while, generally speaking, I like Ubuntuâs new Unity interface, I know some people really dislike it. So, who better to explain why Unity looks and works the way it does than Mark Shuttleworth, founder of Ubuntu and the company behind it, Canonical?
Shuttleworth opened by saying that the main point of Ubuntu 11.04 with Unity was âto bring the joys and freedoms and innovation and performance and security that have always been part of the Linux platform, to a consumer audience.

Read the full article at:
Shuttleworth on Ubuntu 11.04 Linux and Unity

PMP Certification: Is it worth it?

Pam Stanton's verdict:

In summary, here’s how I see it. Getting a PMP certification won’t hurt you, and it may expose you to some useful tools and ways to organize projects. It won’t, however, make you a great project manager—that you’ll have to earn through blood, sweat, and tears, and hopefully some laughter.

What does hurt all of us as a profession is the misconception that a PMP certification is an assurance of competence, and that’s where I’m passionately opposed. I seek to drive balance and visibility to the real skills that make or break a project manager, which is the emotional intelligence to know which tool to use at the right time, including a deep respect and appreciation for human behavior and group dynamics. As I repeat in my book and speeches: Human behavior is not a work breakdown structure, and methodology alone will not get you there.

My Verdict:

The PMP Certification has great value for non-certified Project Manager's coming from so-called third world economy into a first world economy. Although project management methodologies, concepts, and project execution is the same globally, the PMP certification is undoubtedly a great certification to consolidate years of project management experience with a certification that is well sought after by many international organizations.

Read the full article by Pam Stanton for PM Hut and share your views:
Pmp-certification-is-it-worth-it

How short can your Program Charters be?

Great article by Johanna Rothman for PM Hut.

A great way to destroy a program is to avoid writing a charter. When I do assessments or work with teams, I often find that programs do not have charters, or that the charter is too big, or is missing some key piece of information.
But what do you really need in a charter? Too big a charter and it’s tempting to fake your way through it. Too small a charter, or insufficient information, and it’s not worth the time you spend on it.

I’m not sure there’s a “Goldilocks” size for every program’s charter, but here’s my attempt:

• The program vision. You need a vision or purpose so everyone knows where the product is headed. Depending on the size of the program, the projects that make up the program may need visions also, but you need to know you’re making a cell phone or a refrigerator.
• Release criteria. You need to know what done means for the product so you know when you can release.

Can you write more? Sure. Do you need to? Maybe not. If you’re agile, definitely not, not for the charter. For example, lots of people like to try to discuss ROI (Return on Investment) in a charter. Well, I can lie with numbers, to make the numbers look any way I want them. ROI is a prediction that only starts once the program ends, so that’s not helping the people creating the product.
Remember, a charter is just enough to help you get started. It’s not supposed to be a book, or a thesis, or the reason for the program’s existence. It’s also not supposed to be one sentence, “We’re making a cell phone.” The charter provides everyone on the program the 50,000 foot view of what they are building and how they know it will be done.

Don’t shortchange your program charter, especially if you’re working on an agile program, and don’t overdo it.

Project Decisions

During the life of any project, many decisions must be made. The number and importance of these decisions will depend on the size and complexity of the project, but it is safe to say that any project will have some decisions and managing these is a critical part of the project manager’s job. How you manage these decisions will depend on several factors: whether the decision is yours, whether it is a gating decision, or whether the decision would change the scope, schedule, or budget of the project.

Every decision made on your project comes with a “best before date”. Some “best before dates” are explicit and easily identifiable, others are implicit and require some sleuthing to determine. Your job is to identify the date, identify the decision makers, and then get the necessary information in their hands so they can meet the date. Keeping your eye on these keys to decision making will help your project deliver on time.

Read full article by Dave Nielsen for PM Hut:
Project-decisions