Webinar – 4 Essential PM Skills


On Thursday, November 29, 2012, I’m presenting a webinar for Project World & World Congress for Business Analysts (PW&WCBA) hosted by Institute for International Research USA (http://www.iirusa.com). The webinar is entitled Four Essential Project Management Skills for Small Business.  It will be held at 2:00 PM EST / 1:00 PM CST. Please use the link and information below to join me for the webinar.

Click this link to register for the Webinar:

The Process Dilemma

W. Edwards Deming famously said, “If you can’t describe what you are doing as a process, you don’t know what you’re doing.” I haven’t run into any consultants that don’t know what they’re doing, but there are many who shun process and are stuck in what I call the process dilemma (see More Lessons In Ground Floor Project Management).

“Our dilemma is that we hate change and love it at the same time; what we really want is for things to remain the same but get better.”Sydney J. Harris

The process dilemma occurs when a consultant, a team or a company believes that “process” will slow down project delivery, increase overhead, raises costs, and lead to client dissatisfaction.  In this context, process is usually defined as Project Management or SDLC rigor. Process is seen as inflexible, overly strict, and stifling to creativity.  In fact, as studies and surveys have shown, it’s process that enables project success and allows the creative team the time to create.

The Standish Group has published the Chaos Report on IT project success (or really on project failure) since 1994. The 2011 report stated that only 37%  of IT projects are successful. This would appear to be an indictment of IT Project Management that confirms the Process Dilemma. However, the Chaos Report only considers projects successful if they deliver the defined features on time and on budget.

The 2012 Chaos Manifesto (same thing) looked at project delivery success from 2002 through 2012 (as reported by Mike Cohn and others). The report says only 14% of traditional, waterfall projects were successful.  The report also said that 42% of agile projects were successful during the same time period.

Dr. Dobb’s published the 2010 IT Project Success Rates based on three surveys conducted by their editorial staff. The results are significantly different than the Chaos Report, but so was the survey. Dr. Dobb’s looked at four categories of project delivery methods and found:

  • Ad-hoc projects: 49% are successful, 37% are challenged, and 14% are failures.
  • Iterative projects: 61% are successful, 28% are challenged, and 11% are failures.
  • Agile projects: 60% are successful, 28% are challenged, and 12% are failures.
  • Traditional projects: 47% are successful, 36% are challenged, and 17% are failures.
What does this mean in relation to the process dilemma?  If you use a rigid, highly prescriptive methodology, you are likely to get the same results as if you had no process at all (47% success vs. 49%). I think ad hoc projects may be slightly more successful, because large projects are more apt to be managed using traditional methods. Large projects require large teams, and large teams are more prone to failure. Dr. Dobb’s State of the IT Union survey, a component of the 2010 IT Project Success Rates, showed that team size does matter.  Looking only at successful projects, the survey reported:
  • Ad-hoc projects: 74% for small teams, 58% for medium-sized teams, and 40% for large teams.
  • Iterative projects: 80% for small teams, 68% for medium-sized teams, and 55% for large teams.
  • Agile projects: 83% for small teams, 70% for medium-sized teams, and 55% for large teams.
  • Traditional projects: : 69% for small teams, 61% for medium-sized teams, and 50% for large teams.

Obviously, the probability of success for small teams is much greater. The really interesting thing is that size has the least effect on traditional project teams.

Solution delivery, like project management, can be reduced to the essentials, using agile methods. A “just enough” process approach enriches the capabilities of the team without adding overhead. It can keep costs down by managing customer expectations within the product backlog instead of negotiating frequent change orders. Most importantly, an agile approach fosters creativity, trust and teamwork by putting development decisions in the hands of the team and the client product owner.

“We realize our dilemma goes deeper than shortage of time; it is basically a problem of priorities. We confess, We have left undone those things that ought to have done; and we have done those things which we ought not to have done.” – Charles E. Hummel

Solving the Process Dilemma is in itself a process. It can take a change in attitudes or a complete culture shift. The key is on the ground floor. Build a solid foundation on practical process that ensures you are doing the right things at the right time, and you will get the right results.

More Lessons in Ground Floor Project Management

Trying to add value as a Project Manager to small projects that have no more than 10% of the total effort dedicated to project management is challenging. I pointed out in the last post that the challenge is to find the basic PM practices that are meaningful and valuable to the client. What is really needed are the essential practices — a small but important difference. Two essentials are communication and measurement. What are the others?

More Lessons

The two other essential skills, tools, and techniques the PM needs to bring to projects are Change Management and Risk Management. In most small and really small projects, these are overlooked until it may be too late.

Change Management – Too many times, small consulting projects are scoped and estimated based on a couple of hours discussing needs and wishes with a client. A task list is generated with time and cost estimates, but there are no clear guidelines for what other necessary tasks fit within the scope and what tasks don’t. Further, when undefined tasks start to push the work over budget, many consultants will absorb the hours — in other words, perform the work and not get paid for it — to build or maintain the client relationship.  This is part of what I call the process dilemma, which I’ll explain below.

Risk Management – Risk identification is not done consistently for small projects. Even when risks are known and documented, it’s rare to find any kind of risk management plan. Monitoring, planning for and responding to risks are never included in the task list, and I would venture that some clients would consider this activity out of scope, because it doesn’t directly deliver functionality. That mindset and how to change it will be the subject of another post.

The Process Dilemma

Most software developers, whether they are coding a product, a custom application or contracting in a staff augmentation capacity have a few things in common:

  • They are overly optimistic in their level-of-effort estimating
  • Their estimates usually include only code and unit test
  • They think anything else is just overhead

The line of reasoning is, “I should be spending time writing code and building something rather than on ‘process’.”  In reality, not following a development and delivery process — one that includes communication, change management, and risk management and that reports progress against known, agreed upon metrics leads to projects that are delivered late and over budget for a number of reasons.

Another aspect of the process dilemma is  that all consultants and product developers say they have a delivery process. They just don’t use it.  It becomes the job of the Project Manager — the person who is given less than 10% of the budget — to champion the process. It’s not for the sake of methodology or too pile on hours to make more money. It’s for the consistency and predictability that comes with having repeatable processes.

Strip project management down to its essentials and there is no room for administration and overhead. And it works.  Obviously this is the tip of the iceberg. Future posts will explore the process dilemma more fully.



Ground Floor Project Management – Lesson One

It’s been nearly a month since the last post. It turns out, working and blogging both take a lot of time. During this month I began a weekly project management review of all consulting engagements in progress for one of my business partners. And, I helped kickoff a couple other projects for another partner.

The Projects

All the projects have some things in common:

  • They are all small in terms of hours — anywhere from 70 to 400 hours.
  • They are almost all software projects that have one developer on the team.
  • They are almost all follow on projects with previous clients.
  • None of them have more than 10% of the total estimated effort earmarked for Project Management

Looking at this portfolio of work from a traditional project management perspective, it’s hard to see how a PM could operate in this environment. The industry standard of 12% to 18% of total time originally published by Capers Jones is barely in the ballpark.  Even looking at the work from an agile perspective, a Scrum Master or other agile project leader would dedicate as much time to the project as the rest of the team.

How does a Project Manager, especially a PM who has no history with the clients or context for the work currently in progress, add value to the process of delivering these products and services to clients?  What project management practices are basic and simple (remember – you get 10% of the estimate) yet important enough that they really will make a positive difference in on the delivery process, product quality and client satisfaction?

The Lessons

Communication – This should be no surprise to anyone. Open, honest, clear, concise, frequent communication is the key to everything a PM does, regardless of what methodology he or she is following. In a brief weekly interview with each project team we have identified, updated and documented issues, risks, constraints, and dependencies that had not surfaced in other communication with the client.

An ability to ask probing questions and follow up on incomplete answers is a necessary skill. In the case of this partner, creating a weekly client status report containing all the findings for the week was another value add.

Measurement – In many small projects, it’s too easy to leave progress reporting until the end. There is no way to give a clear picture of the project status to a client without some fact-based measurement of progress. Fact-based is the opposite o the 25% or 90% (your choice) complete answer most developers give until their code is released.

My partner and I established four statuses for each task in a project. A discussion of the status of each task is part of the weekly interview. Many times, tasks that are not called out in the project plan take up time (more on this next time). Measuring and reporting the time helps the developer and the client know when the budget and/or timeline are at risk.

Next post – Lesson 2: Champion of the Process

Ground Floor Compliance

Compliance is a fact of life for almost all businesses in almost all industries. Every healthcare provider is familiar with the information confidentiality restrictions of HIPAA. Financial services firms are highly regulated, as well. But how many small and midsize businesses (SMB) think about compliance with the Patriot Act, homeland security rules or anti-money laundering regulations meant to prevent the funding of terorism?

Outside the specific regulations of their business sector, SMBs don’t spend a lot of time thinking about compliance with standards that are not mandated by local, state or federal law. That’s one reason PCI compliance is not universal.  In a study published in August of 2009, SC Magazine reported that only only 62% of merchants processing fewer than 20,000 payment card transactions per year were compliant with the PCI Data Security Standard.   That number may actually be high, compared with other, newer data.

These small businesses, classified as Level 4 merchants by the PCI council, made up 99% of all credit card transactions in 2010 according to Bank of America. And yet, surveys show repeatedly that Level 4’s, especially small Level 4’s with 10 or fewer employees, don’t think they are at high risk for breach or fraud.

In their Third Annual Survey, Control Scan reported three important findings regarding Level 4 merchants:

1. Risk of financial losses doesn’t seem to be a big motivator for Level 4 merchants to aggressively comply with the PCI DSS.

2. A sizeable minority of Level 4 merchants continue to believe that PCI compliance does not make their business more secure.

3. Little progress has been made in increasing awareness of PCI compliance among small merchants.

How can small merchants be convinced that PCI compliance is a good investment? It really goes back to the ground floor philosophy. The security desk is on the ground floor, not the top floor. The intercom to gain entry is at the front door, not the entrance to the roof garden.

So, start where your business is most vulnerable — where your payment card processes face the customer. Examine the controls in place to protect your customers and your business when you swipe a card.

Next, look at internal threats. For all the good intentions small business owners have, an ounce of prevention will go a long way when it comes to protecting cardholder data. Secure paper records. Make sure reasonable measures have been taken to improve the security of electronic data and communication.

Finally, determine your responsibilities as outlined by PCI based on your payment processing methods. If you are unsure which SAQ to use or what is required to be compliant, leave a comment here to have Berman Consulting Group, LLC contact you.  We provide trusted adviser services to help you become PCI compliant.


Just Google Yourself

This is a little departure from my usual topics to talk about the importance, or triviality, of your presence on the internet.

Every brand marketer and web-savvy business consultant will tell you to google yourself every so often to see where you rank in the results. Even if you have a common name, they say, you can find ways to raise your page rank if you try.

Never one to disregard good advice, I googled myself. I searched for Dave Berman and David Berman, and the results were not surprising. Whether you believe it or not, Dave Berman is a common name — at least in cyberspace.

Who are we?

The first and most common David Berman you can find in a search engine is theDavid Berman - not me former leader, songwriter, and driving force behind the indie rock band Silver Jews. One thing I find fascinating about this David is that he outed his lobbyist father on his record of raising money for conservative causes through nonprofit shell companies. There are news articles and YouTube videos if you want the full story.

Once you get past the David Berman who is in the cast of CSI, there is an array of lawyers, doctors, communications executives, personal trainers and others with whom I share a name. No wonder it’s so hard to find a domain name, twitter handle or user ID that is unique.

The whole point of this post is that somewhere, several pages into the search results, I found Davie “the Jew” Berman, a Russian who became a gangster after immigrating to this country. Of all the D. Bermans, this guy is my favorite. He started his life of crime in Sioux City, Iowa, where my father grew up. His only child was a daughter, Susan — same as my sister.

I just find this hilarious. He didn’t have any professional certifications or add to the knowledge base of his chosen profession. Yet, there he is much higher in the page rank than I. Possibly thanks to Wikipedia.

Who Am I?

So, how can this Dave Berman differentiate himself? One way would be to talk in the third person all the time and annoy everyone. A better idea might be use my PMP, CGEIT and CSM certifications to provide quality, ethical, cost effective service to my customers. I’m old fashioned enough to think that word of mouth is still a viable communication channel. My position in the “ground floor search rankings” (a term I just made up) is equally important. I like to know what real people are saying.