Do you struggle with this too?

It can take different forms:

• ‘Doing it yourself’ when it would be better to let someone else handle it.
• Gold plating, which is adding more features because you think they are ‘cool’.
• Putting extra effort towards something other than your product without any potential value to the customer.

And more..  Heck, I’ve caught myself doing a few of these just recently. The other day I received an email from a new student of my online project management training. There were warning messages showing up all over the place, and she never received her login details after purchasing access to the course.

I jumped in right away and fixed it as soon as I could. It turns out my web host had upgraded their versions of PHP and mySQL, and the software I purchased to deliver the training was using some old, deprecated PHP functions.

But as I was sitting there debugging the code a question crossed my mind.

Why am I doing this?

Doing It Yourself

I resolved the issue. I can debug php code on my own server. But should I be?

Should I even be hosting this on my own server where I’m responsible for all of the configuration, design, etc?

Would this problem have happened in the first place if I didn’t insist on ‘doing it myself’ and let a team of people who are really good at avoiding problems in the first place do it?

The answer is no, it wouldn’t have happened. My students would receive a better experience and I could have spent more time developing new training material or writing to help more people, instead of debugging code.

So I’m looking into migrating my training courses to a new platform, hosted by a company who knows what they are doing.

I just freed up a few hours per week of my time to do more teaching and writing. Sweet!

Gold Plating

Sometimes as developers we think we know what the customer wants better than they do.

It’s true that sometimes they don’t know what they want until they see it. There have been several occasions in my career where I had my teams develop prototypes ‘on the down-low’ to show to a customer because we knew they’d love it when they saw it, and authorize us to proceed. And most of the time, we were right.

But gold plating occurs when you go further and fully develop new features in a product without the requisite assessment of need/value from the customer and without accounting for the additional work in your schedule and budget.

And yes, I’m guilty of this too. There are several aspects of my online training that I spent considerable time on that no one uses. If they were scaled-down features to be used for experimentation to gauge student interest that I could enhance later if the need was justified, excellent. That’s iterative development, and is wonderful. But I spent a long time on some of these features that are now happily hosting a family of pet dust bunnies.

Fluff

New project managers fall into this trap all the time with documentation. I know I did.

You spend tons of time on a project management plan because you want to make sure an auditor who might review your work would say “You get a gold star for making it look important, especially with all the flowery language and the fact that it’s 300 pages.”

Yea! You can knock someone down by throwing your plan at them.

Here are the lessons I’ve learned and want to convey to you about documentation:

1. Identify the ‘customer’ of your documentation clearly
2. Every word must add value to the people you identified in # 1
3. The shorter and more concise, the better. The people in # 1 might actually read it.

If you can play bull$#!t bingo as you read through your documentation, try again.

Better yet, put your bull$#!t detector hat on as you are writing it in the first place.

Just because you can doesn’t mean you should.

What are your examples of doing something you shouldn’t have?  

Come on, it’s very therapeutic.

It’s easy, just start with something like “Hello, my name is Josh. And I’m a gold-plater.”

Original link: Just Because You Can Doesn’t Mean You Should

No related posts.

Guest post by Dr. Ian Clarkson

Why do projects fail? Problems can manifest from anywhere on a project but there are several elements of a project that if managed poorly could mean that the project may fail to deliver:

Poor sponsorship

If the people at the top are not supportive this will severely hamper or even stop the project delivering. Clear job descriptions from an executive can often reduce the chances of this happening.

Unclear requirements

If phrases such as “easy to use”, “state of the art” or “best of breed” have sneaked their way into the requirements, they will be virtually impossible to prove. Project managers should view ambiguity as their worst enemy, and strive for clarity.

Unrealistic timescales or budgets

Too often the customer/sponsor asks for the impossible, but a project will take as long as it will take. As Henry Ford said – better, faster, cheaper, pick one!

Scope creep

This describes the phenomenon where changes mount up to slowly push the product away from its original design. Clear documentation and a robust change control mechanism are vital if this is to be avoided.

Poor risk management

If you analyse the situation before proceeding you may be able to identify potential problems and work around them before they even happen.

Poor processes/documentation

If you don’t follow processes and document events and requirements properly, do not be surprised if things do not happen the way you want them to.

Poor estimating

Good project managers don’t guess! Use historical information, formulae, and lots of questions to make sure that your estimating is not GUESStimating.

Poor communication/stakeholder engagement

People tend to fear what they don’t know, so it is always the case that a bit of communication about what is going to happen will go a long way. Communication with stakeholders is vital if the project is to capture their imagination, and keep it.

Poor business case

A good business case will clearly demonstrate the business benefit of delivering a project and so will allow the project team to sell the project to the business, and constantly monitor whether the project continues to remain a good idea during the project.

Inadequate/incorrectly skilled resources

Having people who are ill-prepared to complete a task can be worse than not having anyone. To give yourself the best chance of getting the resources, be clear about what you need and when you need it.

Dr Ian Clarkson is Head of Project and Programme Management Product Development a QA -leading providers of Prince2 courses. His role provides business direction and ownership of QA’s portfolio, programme, project and risk management curriculum. Ian is an experienced lecturer, author, speaker and consultant, having delivered programmes and projects in all industry sectors.

Original link: Top Ten Reasons Why Projects Fail

Related posts:

1. 5 Reasons Your Project Management Career Isn’t Moving (And What To Do About It!)
2. 4 Steps To Recover From a PMP Exam Fail

I have learned sooooo much over the past decade that I’ve been managing projects.

So when Terrell asked for sharing lessons learned, I was all over it.

My blog and project management training pretty much are my lessons learned from over the years.  The great thing about having written this blog for 5 years now is that I can easily search my website to either jog my own memory or provide a resource for someone else who can benefit from my experience.  Avoiding mistakes by focusing on lessons learned is extremely important.  I even created a collaborative template for capturing lessons learned in project management for people to adapt and use.

Because I write and teach about the myriad of different aspects involved with project management, there is a lot of diversity in my lessons learned resources.

Trust me, even though it may seem like I’ve got it all figured out, I have personally screwed up each and every aspect of managing teams and projects at least once.

Here are a few specific ones I’ve written or done training for.

• Delegation
• Project Management Plan
• Scheduling
• WBS
• Requirements
• Agile and Batch Sizes
• Effective Meetings
• Coordinating Multiple Project Teams
• Agile User Stories and Waterfall
• The Power of Focus on Projects
• Continuous Integration & Testing
• Landing a job and gaining experience

Original link: Lessons Learned in Project Management

Related posts:

1. How To Get Into Project Management

It happens to all of us.

You’re a developer or a project manager and here comes the customer or stakeholders asking about how to cut a few corners.

Your spider-sense should be tingling, because usually this will cause you more pain than it’s worth.

Get the Full Perspective

In order to make a decision like this, you need to weigh the pros and cons.  Unfortunately, we humans are good at estimating short-term impacts in our immediate surroundings, but terrible at knowing what long-term impacts may occur in areas we don’t really deal with much.

In the case of trying to take shortcuts on your project, it’s really easy to fall into the trap of changing your plans and adopting an approach that feels pretty good at the time.  Change is good and new information should influence your plans and approaches as you progress through projects.  What I’m talking about is trying to get by or ‘get by for now’ in the hopes that everything will turn out all right in the end.

One of the reasons I enjoy working with agile and lean processes is the focus they put on perspective.  Daily stand-up meetings, frequent releases and feedback, user stories….all of these things help foster a fuller perspective of the functionality being developed, especially when it comes to changing mid-stream and being able to assess the impact.

Whatever processes you use, be sure they allow you to have a full perspective.  If you are making decisions without thinking through impacts to other interfacing systems, maintenance time and cost, scalability, or flexibility, you are doing it wrong.

Sell It

Sometimes you and your team know what the right approach is, but your customer and end users aren’t seeing it.  Sometimes corner-cutting got worked into what the customer wants…they want it to be a half-@$$#& product.  It’s crazy, I know…but it happens.  As the project manager, sometimes you must take it upon yourself to educate your customer about what is good for them.

Years ago, I worked on a project to overhaul the reporting systems within an MIS department.  What I found were analysts who were spending the majority of their time doing data entry and copy/pasting, instead of analysis.  Many of them had been in the same role for 20 years or more.

Here I come, a project cowboy wanting to disrupt their world.

Cutting corners and doing enough to get by is what led to the place they were in.  As new requests and data sources came in, they continued to cobble together new processes with duct-tape and chewing gum.  People couldn’t be out sick, because everyone had their own little ‘niche’ of processes that only they knew.  They felt secure and needed in their roles, but were hobbled by the chains of their own making to the point they couldn’t really add much real value to the business any longer.

The only way to combat such a thing is to step back, assess what will create some real value for the organization, and go do it right.  Cutting corners doesn’t create value…it leads down a path of slow deterioration with hidden costs that will slowly kill from the inside.

I spent a good deal of time convincing and demonstrating to the end users and their management that I wasn’t automating them out of a job… we were empowering them to do something amazing.  Actual analysis work.  It was a lot of prototypes and demonstration for me and my team.  Slowly, we guided them down a path towards sharing a vision for how good it could be.

I still remember the first time one of the analysts discovered a problem with a specific site through data mining and doing real analysis work to find a pattern no one else could see.  This veteran who so strongly resisted change of any kind in the beginning.  She was the toughest sell, one who kept telling me she didn’t need this or that functionality, because she already had a tried-and-true method to do something like that already.  The fact it took her an hour to put something together versus a few clicks of a mouse with the new system didn’t enter into it at first.  She slowly came around, but I had to sell her on it.

I remember the look on her face, the bright smile of real accomplishment, real value delivered.

It was beautiful.  There were no shortcuts to get to that place.

Original link: How Cutting Corners Costs You More

No related posts.

Project management is one of those things that seems very complex when you’re starting out. But after you been doing it for a while, it really turns out to be a good dose of common sense with some science and discipline added in.

I think many project managers tend to focus on tools and techniques far too much, and not enough on the people aspects of managing projects. By far these relational aspects of project management are the most important ones.

I recently had someone comment about my online project management training.  They liked it, but it seemed strange that instead of pouring through multitudes of esoteric details what I was presenting was rather simple, a “no BS” way of just showing how to do things and illustrating the important concepts.  High praise to my mind, and I’m still glowing from it.

If you are a new project manager or someone who’s getting into project management for the first time, I urge you to keep something in mind.  After you learn some of the formal techniques that come along with the discipline of project management, this is about working with people.  Most of the real progress I’ve made in the way I manage projects has been the result of understanding human psychology better in some way, not by understanding a tool better.  Most of what works in terms of tools and processes is rather simple, and if you understand the core fundamentals, you can adapt your approach to any situation.

Manipulating numbers in the spreadsheet or a Microsoft project file doesn’t make reality happen. Planning is important, but the actual plan itself is much less valuable than the process of creating it. I have known a lot of project managers over the years who do an excellent job at managing projects and teams, even though they have never gotten a degree in management or a certification in project management. That said, I do think that even those project managers would be better at their jobs if they approached it as a discipline.

For instance, in my journey to approach project management as a formal discipline, I have discovered many “common sense” assumptions about how people think to be just plain wrong.  Anchoring in project estimation is a perfect example of something people do every day without realizing it.  Another is the ubiquitous multitasking that happens in workplaces everywhere.  It’s what happens when you don’t take a disciplined approach to managing work flow.

At a high level the way that I manage projects follows a particular process even though the individual implementation is going to change on every single project I manage.

• I start with the why,
• then figure out the what,
• then figure out how it will be done and who’s going to do it.
• When comes out as a result of these things
• and then there’s a process of iteration where we update our draft plans in light of reality including funding.

There are always trade-offs involved, considerations about the individuals that will be on the project teen, who is paying for this, et cetera. Generally I like to make my project management processes as lean as possible and as iterative as possible so that we have continuous integration and a very good understanding of exactly what it is we are supposed to be producing. Feedback loops all over the place are excellent as well including

• daily tag-ups,
• lessons learned,
• retrospectives,
• putting prototypes of the product in front of the customer,
• mockups,
• user stories,
• and many other techniques that allow you to gather feedback from stakeholders.

So don’t be intimidated by project management. When you look at something like the PMI standard or other certifications and standards having to do with project management he can seem really complex and convoluted.

But in the end, good project management is common sense.

Original link: Good Project Management is Common Sense

Related posts:

1. What Is CAPM Good For?

Serendipity happens.

I responded to a student Inside pmStudent e-Learning with what turned out to essentially be an article about criteria for project success and failure.

A few days later, Shim wrote “Projects failure rate – the conventional wisdom is wrong!” on his fantastic blog.  I started leaving a comment, and it became one of those comments that should really be it’s own post.

Chaos

What I really mean are the set of reports out out by various organizations on project failure rates.

Shim listed the following on his post:

1. Chaos Report (1994) – only 16.2% of projects were successful by all measures. Of the 70% of projects that were not successful, over 52 percent were partial failures and 31% were complete failures.
2. OASIG survey (1995) – the IT project success rate quoted revolves around 20-30% based on its most optimistic interviews.
3. Chaos Report (1995) – The Standish Group research predicts that 31.1% of projects will be cancelled before they ever get completed. Further results indicate 52.7% of projects will cost over 189% of their original estimates.
4. KPMG Canada Survey (1997) – 61 % reported details on a failed IT project.
5. Conference Board Survey (2001) – 40 % of the projects failed to achieve their business case within one year of going live.
6. Robbins-Gioia Survey (2001) – 51 % viewed their ERP implementation as unsuccessful
7. Dr. Dobb’s Journal (DDJ) Survey (2007) – 72% of all Agile projects were successful, compared to only 63% of traditional of Data Warehouse projects.
8. Chaos Report (2009) – Only 32% of projects have been defined as being ‘successful’ compared with 35% in 2006.

See Shim’s comments section for some great commentary from the likes of Glen Alleman, Steve Romero, and Pawel Brodzinski.  I share the skepticism of these reports.  I’ll put that aside for a moment.

Controls

These are all observational studies, with all the limitations that come with that class of research.

How do you control for the variation between organizations, the people in them, and the subtleties of culture and methodology?

For all practical purposes, you can’t.

Was an implementation of EVM, configuration management, Kanban, Agile, or Waterfall more or less effective due to the charisma or skill of the individual leading the charge?  How do you control for charisma across project teams, organizations, countries, industries?

For all practical purposes, you can’t.

If you want to gain real knowledge from a study, it’s got to be an experimental one in my book.  As with all experiments some are better conducted than others.

See the studies I reference in the following for some examples of experimental research into human psychology that can actually be applied to better our projects.

• How Expectations Mess Up Project Estimates
• What’s That Got To Do With The Price Of A Cordless Keyboard?
• Do Your Project Teams Suffer From Chronic Media Multitasking?

Applicability

What’s the value of these reports anyway, besides being a mechanism to trigger fear of failure in sales prospects for project management consulting and software that will ‘fix the problem’?

Even if these reports were an accurate reflection of the aggregate, does it really mean anything to you?  Can you equate the state of behaviors and results in your little organization or program to the aggregate?  Certainly not.  See Controls.

False Dichotomy

There is a logical fallacy called the false dichotomy.  In this case, you would be led to believe there are two states for projects; success or failure.

Reductio ad absurdum can be a useful tool to uncover these false dichotomies.  Allow me to demonstrate.

On the axis of cost, a successful project has met its budget.  It was $100,000 +10%/- 5% for a total budget of $110,000 assuming G&A and reserve in that final budget.  That’s your max spending with all thresholds and reserve taken into account.

You spent $109,995 and got the job done.  Close to the max budget but still within range.  Success!

Oooooops.  A $10 order of post-it notes for your Kanban board was missed.  Now you’ve spent $110,005.  Failure

You could do a similar exercise with any attribute of the project.  My point is that project success is not a binary or if-then calculation.  It is a continuum, and is likely to be a different continuum for each and every stakeholder involved.

Can you say you successfully met or failed to meet the terms of a contract?  Yes, if it’s written well.

Can you say you successfully met or failed to meet the criteria with thresholds of your EVMS/PMB?  Yes, if your system is good enough.

What impact do the above conditions have upon the opinion of Larry, Sue, Dave, Kim, Robert, John, Laura, Sam, Roger, taxpayers or Huckleberry Finn?

For that matter, what would Rufus T. Firefly, Otis B. Driftwood, Horatio Hornblower, Ebenezer Scrooge,  Ace Ventura, Benovan Stanchiano, Scut Farkus, Buckaroo Banzai, or Apollo Creed say?

Eye of the Beholder

Some people say that as long as the requirements are met (verified) it’s successful, even if it isn’t useful (not validated).  I disagree.

How about these 2 criteria?

1) Are the stakeholders happy, especially the key stakeholders?

This is everyone, including the project team.  If you drove your team to quitting the company, the project was probably detrimental to the organization.  A project is an end to a means, not an end in and of itself.  If you are not benefiting your company, employees, and customers as a whole group, then why are  you running projects?

2) Does the project fulfill the configuration-controlled and managed performance measurement baseline (PMB)?

I laugh when I hear about projects being ‘over budget’.  That doesn’t really tell you anything.  If you are using change control processes to manage scope, schedule, budget, and quality and you finish the project within the thresholds set, you’re fine.  People look at these massive projects where the total spent is double than the original proposal and think they are automatically failed projects.  To the public who was told it would cost $50MM who finds out it actually cost $100MM, it’s a failed project.  If you are blind to any change control process you can easily think of this as a failure, even though it may have been a resounding success to many other key stakeholders who were directly involved.

A little ranty, I know.  But I had to get that off my chest.  A penny for your thoughts?

Original link: Project Failure: We are at it Again

Related posts:

1. How To Assure Project Failure