Implementing an audit function

2009 is starting off great. Am working for a new manager with a renewed mandate towards excellence in project management. Goodbye to my old manager, I learned very much from him. The challenge I've always encountered is how to bring the rest of the organization along for the journey. This challenge never stops, it just morphs into another facet.

The question that comes to mind is.. is this a curse that I've brought upon myself. Some of the kind words from my departing manager was that he doesn't know of anyone who is so dedicated to learning and growth as I am. Maybe he needs to get out more. But it is true to some degree, I guess. I am always reading books on project management, listen to a full collection of audio files from prominent podcasters, am an avid web surfer, and regularly attend my local chapter meetings. I guess this puts me somewhere between insane and passionate about my profession, or extremely fearful (probably). Anyways, so what is the burning interest at the moment.. implementing an auditing function.

I must recommend a good book by Gerrad M. Hill - "The Complete Project Management Office". Amazon link

What is the audit scope of the Governance PMO acting at arms length to the actual project management office? The PMI program management standard seems a bit light duty on the subject. It indicates that the audit function has a financial interest as well as a project management process interest, but leaves the reader wanting. For this I recommend reading Mr. Hills books. It takes the reader off the deep end. Great job Mr. Hill.

A bonus to those of you reading this who are also active members of PMI, go to the PMI website ereads and reference section. You will find this book available online. In the end you will likely come to the same conclusion as I did, it is worth the purchase.

Still though... how does one manage to influence the organization to adopt being audited to such a degree. Mr Hill suggests that an audit may take several weeks, and is conducted using an audit team. So far this has landed like a lead balloon... 1 yay, 4 nay, 2 remaining. I guess people are either too busy, or see little value in investigating with the potential outcome of informing the project leader and sponsor to do things differently.

Being an avid enthuiast in project management excellence has its drawbacks. Being able to let go has its advantages too. Back to the kind words of my previous manager, "sometimes it may take a year before people realize what you told them back then actually makes sense".

Training Effectiveness

Just finished delivering Project Management training today. Tried to convey 8 hours of material into 4. Some things have a limit, and I now know that the lower limit is greater than 4. Feedback is a great thing, and it wasn't lost among the participants that there was too little time.

However so, this does not mean that the content needs to change, more the delivery and setting realistic expectations. The group initially requested an understanding of the tools. As such, theory was kept down to a minimum which allowed for more depth when tools and templates were involved. Informing the group that we may skip some of the theory in order to satisfy their interest in the tools sounds like a good strategy in hindsight.

To set the record straight, the feedback I received was very positive overall. So hopefully if you find yourself in a similar situation (which I know I will two more times over the next month), then you will be able to achieve that Utopian balance. It is tough to discard anything when your very passionate about a subject, isn't it.

Blinded by the dashboard lights

Most projects include the same basic collection of performance metrics. They comprise of the usual triple constraints; schedule, cost, and scope. However so, projects will likely include other non-typical performance metrics too. These metrics are often unique. As such, it is left up to the project leader to translate their performance for reporting out to the dashboard.

Translating performance requires an understanding of the message inferred by each dashboard status indicator. Let’s consider a four colour traffic light scale comprised of Blue, Green, Yellow, and Red. In this scale, Blue represents the highest degree of performance and Red is the lowest.

The message for Blue is that the metric is over achieving, it is doing GREAT! Subsequently, when status is Green, your achieving results as reasonably expected. Yellow indicates that issues are impeding performance, yet are manageable within the project team. Lastly, Red indicates that issues impeding performance are outside the control of the project team, requiring executive steering committee or sponsor intervention.

Here is a conundrum for you to think about. Consider that you’ve completed all the work planned, within the allocated budget, and to the satisfaction of the customer / stakeholders. How would you rate your performance? In my opinion, I would choose Blue, recognizing the ability to successfully deliver amidts the uncertainty. Other people may choose Green, stating that what was achieved was what was expected. My opinion does not come without caveats. It is based the opinion that in most cases, project leaders will be working within a tightly constrained environment. They will encounter difficulty and make compromises while achieving project objectives. What is guiding your opinion?

Some facts pertaining to projects:
Projects by definition are temporary and unique. This introduces a degree of uncertainty and risk that will mitigate performance. Therefore it is unlikely that a project will attain a perfect score each month. There can be cases where we find that a perfect score is achievable each month. This could occur in projects that have transferred all risk, such with firm fixed price contracts. It could also occur where planning, execution, and control activities were painstakingly and rigorously followed. This could also occur where there was sufficient reserve capacity available. Hopefully this isn't occurring due to inadequate performance translation or misreporting.

2007 Wrap up

Hello all. It has been a couple of months since my last post. I haven't gone anywhere, just prioritizing between hobbies.

I noticed a few open discussions from my previous posts. I'll take a moment to update you on these and then open up with some new insights.

Project Performance Index:
Remember this is an assessment of the project performance as it pertains to alignment with Business Objectives / Support, Project Methodologies, and Team. The target was to achieve 80% performance. Well this target was never met. I surveyed many different projects, from small to large.

Results usually indicated:

1. there was a need to improve business alignment
2. project methodologies were a bit confusing but not excessive
3. team performance was good to great

Fyi - I am skeptical that team performance is as good as people say it is...

I believe this measure is worth continuing in 2008. There have been some difficulties getting project leaders to buy into using it. I believe that most see it as a low value exercise. Perhaps you are of the same opinion. The glimmer of hope is still with me for now.

Moving on.. Updating the project management guideline used in our organization

This turned out to be something totally different than what was envisioned. If you recall, the original intent was:

1. update the existing project management guideline
2. add sections for program and portfolio management.

Well #1 was accomplished. There were quite a few references to the old program management office committees, templates, and other obsolete recommendations. So updating this was a good thing (it also reminded me of the original recommendations that are still in effect).

#2 came about in a much different fashion. I actually like where it went. Instead of adding new templates, recommendations, etc.. the program and portfolio morphed into a process flow diagram for Enterprise Portfolio / Program / Project management. This flow diagram addressed the need to formally establish the expectations for selecting and managing projects. You see, although we have guidelines, they are loosely followed in most instances. Therefore instead of creating yet another edition of a guideline it made sense to set expectations first. This flow diagram will take awhile before it is accepted. In the meantime its timing was very appropriate. You see we've just purchased a new pm software program. This flow diagram will provide a great model for the governance configuration.

Now on to new information.

Books.. This year I managed to read some great books. Some were project management specific, others were about benchmarking, change management, and time management. One book by David Allen - Getting Things Done has caused me to make a dramatic change in the way I accomplish work. I wholly recommend to anyone out there to keep up with your reading. A word of advice, consider why your reading the book. My preference is to learn. Therefore I often find myself re-reading a paragraph because I didn't understand it.

I'm currently reading a book about Project Metrics; by Parviz F. Rad and Dr. Ginger Levin ISBN: 1567261663. It is a difficult read, consisting of complex sentences and references to figures located on other pages. I am really enjoying this book nonetheless. I am only into the second chapter but I would recommend it for the experienced project manager. The reason I don't recommend it for the new project manager is that in my opinion, your success will come from understanding people first, template second.

Well.. enough of this post. It has been good just to catch up. I hope everyone had a great 2007 and are looking forward to a great 2008.

Syd

Revise Project Management Guideline

Hi out there. According to my spy in the sky, there are actually some people out there who are reading my blog. Yippee!! And to top it off, some of you are repeat visitors.. The wonders never cease.

Ok, so for today's post, and for the subsequent near future I figure it would be appropriate for me to talk about my current challenge:

"Revise the internal Project Management Guideline to include portfolio and program framework, and enhance existing project guidelines; establishing specific requirements based on tier criteria; incorporating the collaborative input from representatives of the affected stakeholder management within XX, YY, ZZ, AA, and BB; and engaging in discussions towards the capability maturity framework established in the Organizational Project Management Maturity Model standard "OPM3" developed by the Project Management Institute"

How about that!

I figure that this initiative isn't going to get legs under it unless I structure and execute it as a project. Do any of my readers have comments towards how they tackled a similar objective like this one in the past? The first thought that comes to mind is communications. I need to ensure that my target audience is working with me through the critical steps in the process. Have you noticed how no matter what, communications seems to be very difficult to get right?

Note to self - Be careful when drinking from teucu container.

Back to the project... so if communications are so challenging, then I had better allocate a good chunk of my energy towards that. What then are other high priority success factors
... being organized
... being integrated with other methodologies
... demonstrating value
... gaining momentum
... staying focused
... getting direction from end users
... influencing in accordance with best practice
... being in sync with organizational values & drivers

Well that is a pretty short list but I think there are some key items mentioned. One thought that came to mind is the OPM3 guideline for initiation processes and best practice. Reviewing this may also provoke some additional insights.

Wish me luck.. Hopefully I'll post some positive results the next time you visit.

Managing the Confusion - Teaching Project Management

It has been quite busy the last month which has prevented me from updating the blog till now. Actually, don't tell anyone but I'm supposed to be updating a PPT presentation that is due Monday.

Now unless your an accomplished teacher then this tale of my experience will be of interest to you. You see, the PPT presentation I'm supposed to be updating is the course content that I will deliver this upcoming Wednesday. I already have the content ready, and delivered it last month, but although full of PM wisdom, I feel that it didn't deliver a compelling message.

Yes.. there are lot's of people out there willing to provide their advice on how to make it better. Amidst the sea of free advice, I have one to share with you that I'm calling Managing the Confusion.

The premise behind "Managing the Confusion" is that people develop a fog in their brain that stops any information from sticking. Therefore you need to wipe the fog away from time to time if you want any new information to get in. The rate of fog build up is proportional with the amount of new information.

Fog Clearing:
Whoosh .. are you with me?? I just cleared any fog that was building up. Can you recall what you just read? I bet for the most part you can.

Now for the PPT (PowerPoint) approach. Clearing the fog needs to be done every three slides of so. The exercise doesn't need to be anything more that asking the audience what they learned. I find that if you can get them to move, then that stirs up the blood flow to the brain.

Whoosh... still with me.. great..
Another exercise is to re-establish what your telling them about. So come the third slide, start off with ... And here we are going to discuss...blah blah (keep the blah blah short) and then go right into.. and what do you think about this..

The gold comes from if you can get the audience to tell you things that you were going to tell them anyways, then when the next couple of slides come up you can say things like .. see, you already know this stuff..

Other points: Keep the slide content crisp and concise. Don't worry too much about expressing the wisdom of the ages.. they will feel much more satisfied by having an engaging experience rather than a class lecture. You will get the opportunity to express the wisdom of the ages if the audience is willing and interested... which will come about as they direct the content, not you.

Good luck..

Project Measurements - Real Data

Ok.. I'm back from sorrowful land. Time to give you an update on the progress towards implementing the Project Performance Index measure.

I'm pretty set now on the three measure categories (Business Performance, Project Performance, and Team Performance). And so far most of my clients have been willing participants to allowing me to solicit their opinion (about their own performance). One client (actually the VP Sponsor) wasn't too interested in me surveying her hot bed project, but gave the green light for me to survey either of her other two. So in the end I got twice for what I was bargaining for.

This month will be the next test. I have to actually report out the results to my peer group. The target value of 80% won't be met so there will be some explaining to do. In all honesty, I'm thinking that reaching 80% attainment in the first quarter of a projects lifecycle is very ambitious. So a note to those interested in implementing this kind of measure, aim for 80% by end of year. The target for the first quarter should be something much less ambitious; say 50%.

Sad Moments; Thick Skin

Just a quick departure from my measurement focus; to say that we project managers need to have thick skin if we are going to survive.

You hear seasoned project managers talk about their scars. These come from projects that didn't go as originally planned; usually in a non-favourable direction. So I am dedicating this post today to all those project managers out there with heavy hearts, for whatever reason you are feeling somewhat dejected, cheer up - your going to wake up tomorrow with the same insane passion that put you where you are today, doing what you love most!

Project Measurements - First Pilot

Yeah!!!.. The first pilot of the new Project Performance Index went exceedingly well today. The project group consisted of 7 team members (plus me = 8). I consider this an optimal size to get a fair cross section of opinions. The team was asked to rate the three performance categories across the range of "Great", "Good", "Caution" and "At Risk". These rating scales are used elsewhere in other project status reporting tools so they were a natural fit to use here.

Before asking the group to rate each I framed up the context within the three categories. This gave them a common understanding of what was to be considered, and hopefully educated them about what is considered important.

Initially I was surprised at the results. The team rated both Business Performance and Project Performance as Caution to Caution - At Risk. And to their credibility, these brutally honest results were shared among the group. However at second thought, I now consider these results as to be expected. The rationale behind this is that the project team has only been together for one month now, and would be feeling somewhat disjointed and unsure about the project.

The real test as to whether doing this measurement was time worth spending is if anyone saw value in it. Fortunately this did occur, and I suspect because not only did we surface some undisclosed concerns, but because we came up with actions to move the rating towards great.

The exercise also gave me further insight towards representative samples. In order to assess project performance across the corporation I need to survey projects at different times within their lifecycle.

PPI - Stakeholder Survey Template

Ok.. here is a model of a template I'm contemplating as part of the Project Performance Index toolbox. This template is a survey for assessing stakeholder engagement. It is one method for testing the business performance component. The survey has 8 categories:

- Risks
- External Dependencies
- Sustainment
- Resource Management
- Strategic Alignment
- Documented Procedures
- People, Process, & Systems Alignment
- Short Interval Control

Each category has one question, posed in the form of a statement. For example, the question for assessing stakeholder engagement for Risks reads:

"I am comfortable that management manages the main risks and issues on the project."

and the 5 possible responses are:
Always, Frequently, Infrequently, Never, and Not Applicable

This design is repeated for each question in the 8 categories.

Here is another example, the question for People, Process, & Systems Alignment reads:

"Training is aligned to address gaps with technical, customer, and process requirements."

Now I don't propose that these questions are very deep or complicated. And that is by design. The intent is to encourage your participants to complete the survey. If you make it too complicated then it will require more effort from them. The end result will be that you trade off quantity versus quality. In my opinion, your going to interpret the results anyways, so why not put the effort back on your shoulders. Remember in an earlier post I suggest that you try things on yourself before engaging others.. well allocating the effort onto you is a spin off from that advice.

Please feel free to forward suggestions on other simple questions to use.

Being cognitive of the...

....

Ok so your probably wondering two things.

1. What relationship does the pygmalion effect have with the Project Performance Index
2. What is the pygmalion effect.

Well according to the book titled "The Knowing-Doing Gap"; by Jeffrey Pfeffef and Robert I. Sutton, it is the power of the self-fulfilling prophecy on performance.

I belive that the pygmalion effect is one of many factors to consider when developing a good measurement set. Another is the Hawthorne effect (you influence what you measure). The pygmalion effect tells us that project performance will be influenced merely because we believe that it will, and visa versa.

So if this is the case, then why go to all the bother to develop and track a measurement system? Hmmm.. the answer is because nobody will want to trust and/or act on faith alone. However that shouldn't preclude you from using this effect to your advantage.

So my advice is to tell everyone how great adding a measurement system to projects will be, and how much better projects will perform once they start getting measured... trust me..

Project Performance Index - Part 1 of Many

I am committing to make this blog posting one of many pertaining to establishing a project measurement system called "Project Performance Index". The interesting aspect of this is that posts will be listed top to bottom, latest to earliest. So I apologize in advance to the reader who may be totally confused about the content they are reading.

In general, the project performance index would be a validation of Business performance, Project Performance, and Team Performance. Tangible criteria that can be evaluated early and often is recommended however this does not preclude using less tangible criteria such as customer satisfaction or instituting change.

Business Performance: Meeting or exceeding the projects value proposition and the sustainment effort required to position the end product for success into its life cycle.

Project Performance: Meeting or exceeding time, cost, and technical performance objectives (ie: delivery of a product or milestone on or before the time it's required, at or below cost, and within the range of design or performance specifications).

Team Performance: Meeting or exceeding the behaviours that ensure the team functions as a unit and not single entities. Collaboration, sharing of idea's, respecting one another, and contributing to a common goal.

I want to close off this entry at this point but before I do I'll leave you with two thoughts;

1. Despite best practices; organizational culture will influence what measures are accepted.
2. I quote a section out of the book titled:
   
   The Complete Project Management Office Handbook
   by Gerard M. Hill (ed)
   Auerbach Publications © 2004
   
   From Chapter 3: Standards and Metrics
   The "standards and metrics" function enables the PMO to:

• Identify accepted concepts and practices for use within the project management environment
• Establish consistent oversight and control for cost, schedule, and resource utilization
• Manage project, technical, and business process performance to desired standards
• Achieve compliance with industry standards, regulatory mandates, and business policies
• Conduct benchmarking related to competency, capability, and maturity goals

These are great points. The next step is to explain what they mean using a language that the people who sponsor and lead projects understand.

Quick and Easy - A tip 4 You

This is a special post - call it a quick tip:

1. Since Communication makes up about 80% of your project; then communicate early and often
2. Don't wait till your project is fully planned before starting; it will only change again tomorrow
3. If your going to insist on doing something, then start off doing it yourself first.
   

Project Measurements

So let's say your interested in measuring the performance of your project. How do you go about this? Do you go for a plain vanilla measurement set; measuring quality, time, cost, and scope? Or do you get a bit more creative and measure team effectiveness, management effectiveness, and project process compliance (risk management, change control, phase closures, lessons learned.. etc).

The altruistic reason to measure performance is so you can do something about it before it is too late. Therefore adopting measures that indicate outcomes of a process will likely be ineffective. These are sometimes referred to as lagging measures. If you want to do something about a process before it is too late, then your going to be in a better position to do so by adopting leading measures. Leading measures look at the process while it is still active. As project managers you recall the control chart (run charts). This is an example of a measurement system designed to provide in process measurements.

So if your considering adopting a project measurement system, consider then that projects get behind one day at a time; and your measurement system needs to be dynamic so that it can give you the timely information required to steer the project back on track.

What is Project Management - really..

I'm getting softer in my ways. Either that, or I am getting a better idea as to the true nature of effective project management. You see, I've been moving away from tool solutions as the goal and instead, spending more time just working the social component.

This social component, is being focussed on the interests of those people who need to take ownership. Being focussed on how they assemble and process information, on what motivates them. Understanding... and then tooling... And if there isn't an appetite for the tool or method, then there is always tomorrow.

The danger with not enforcing rigid adoption of project management methodology is that.. Gosh!.. it is supposed to be the most effective methodology designed to manage projects.. So all the while, when the project leader is busy working by intuition, the project is likely falling behind. This becomes all the more dangerous when there is an expectation that your supposed to be the person charged with the responsibility for establishing the methodology.

Ok.. so does this mean that it is best to avoid letting the project leader's motivating factors lead the adoption of project management methodology, and instead, enforce a rigorous adoption. Heck - why not! My answer is still no.

I don't think I'm soft. But here is the catch. Sure, let the project leader lead. Your role is to interject from time to time with sound project management advice. Look for opportunities to roll up your sleeve and build the missing project methodology into the project. Offer to record the meeting minutes (some places use action logs in place of minutes), speak to them about potential risks - just don't become evangelistic about them.


So what is Project Management - really.. Let's say it is whatever it takes to get the project moving in the right direction, using consistent management processes, and without crushing leader (and the team) motivation while your at it.

Team Performance

Gosh.. here we are in 2007. And my oh my, where has the time gone. Considering that this wonderful blog has only a pittance of updates then I guess there wasn't all that much to rant about in 2006.

I've been actively reading up on team development, methods to keep individuals engaged as a high performing team. The content came from a corporate leadership book that was published back in 1995. My immediate reaction was that this outdated information is not worth the read.. but it was.

There were a number of very interesting strategies mentioned. Each required a dedicated commitment; not quick bandaid solutions.

• Establish currency: The idea here is that you create a monetary reward system that team members receive, and can use to pay others that they depend on to get work done. The currency value is in the form of shares. Share value is determined at a regular basis and is based on meeting the quality, and performance objectives of project milestones.

• Peer review: Team member performance is evaluated by the team. Each member is judged by their peers towards demonstrating the requisite competencies for success. This helps to avoid where team members feel that they are carrying the load for non-performing team members... using team based competencies helps avoid individual local optimization at the expense of others.

Yes, there were many other very interesting options.. but not enough time to write about them today.

Project Closure - what works?

Closure - In my books, probably one of the often mis-practiced components of project methodology. Funny how this is considering that "lesson's learned" can be found in the PMBOK so many times. I don't recall the statistic exactly, somewhere around 200 times. Why do we not practice closure in a timely fashion? I suspect that one reason is because people associate closure activities to signify that the project is completed, and not just that the current phase is coming to an end.

I've yet to find a closure process that keeps people interested. Perhaps something is wrong with the approach? I tend to favor the following:

1. Evaluate what is in scope and do some preliminary analysis
2. Develop a plan that includes tools, techniques, responsible people, and end state
3. Communicate the plan to the responsible people to obtain their buy-in
4. Assume responsibility for the grunt work that is not unique to any one person
5. Review progress to completion

In most cases, this approach and a dollar will buy you a coffee. I think that the strategy goes sour somewhere around step 3. Unfortunately, this is not known until step 5, and step 4 got the go ahead because it was really just an extension of step 2. I believe it is better to do your homework ahead of engaging the team with the plan. However if this the reason why the end result is often less than satisfactory then here are some factors to consider.

1. One could blame the methodology developed in step 2. At times I've elected to employ technological solutions to help out. Perhaps this introduces more risk towards acceptance. I've found that technology is somewhat indispensable in the case with document closure activities. One time I recall having to create a custom database application to help disseminate 50,000+ documents to their rightful home.
2. Perhaps even earlier than step 2, to include the team in the scope evaluation process done at step 1. They may not agree with the prioritizing or level of importance. I've noticed this with closure reports. Despite having a standard report, the fact that this becomes a formal document probably gets people a bit nervous and unwilling to commit.

I could go on and on I guess. Despite my ramblings here we are again in the year end closure phase. I wonder if history will repeat itself.

Maintaining a positive composure during conflict

The saying goes that conflict is not necessarily a bad thing. It is merely an expression of different positions or interests. So why is it then that people perceive conflict in the negative? Why is it that when a conflict situation arises we feel bad about it? Where do we draw the line between being hardened against the feelings of those around us versus not providing criticism for fear that it will not be perceived as being helpful?

To complicate this scenario I refer to the team building model; forming, storming, norming, and performing. I subscribe to the notion that a team will experience each phase, and fall back a notch or two when a new team member is introduced or removed.

Some methods I’ve seen used:

1. Ground rules: This is the preferred approach. It is often used for a long-term engagements yet usually don’t get appreciated as being of much worth. Ground rules can describe a host of circumstances such as being on time for meetings, sending a designate on your behalf if you cannot attend, allowing one person to speak at a time, etc.
   
2. Coloured Cards: If a person is offending another then they can raise a red flag. There are other flag colours for expressing agreement or caution. I’ve seen coloured cards used as a subset of ground rules.

Yes there are many other tools, just refer to the PMBOK Guide 2003 edition under “Develop Project Team”.

Regardless of these tools, I often observe that it is challenging to engage the collective members in a friendly and collaborative context, not one that is perceived as being hostile. And I find the transition from friendly to hostile occurs very rapidly.

So how does one maintain positive composure? I leave off with the question - How do we ensure that all parties are working towards a common goal, and as such, able to accept conflict and criticisms that arise in pursuit of it? I suspect there is no simple answer. As always, your comments are welcomed and appreciated.

Building the Agile World - one vendor at a time

So today we discussed the Agile approach to implementing software. I thought this would be the easiest part of the entire 2 day workshop. Egad... nothing of the sort. The vendor didn't demonstrate a passion towards this approach. I use the word passion because I don't want anyone to think that they weren't willing to consider the methodology.

The customers interest was to have fixed incremental delivery of value, that the business user could touch. Doing so would lead their end users down the path towards acceptance in a timely manner.

The vendor seemed to feel that it would be difficult to stay fixed to a 30 day incremental release as it would be difficult to package subsets of their system modules. They did admit that the business users like to test the modules in lieu of their business processes, and as such, do require only a fragment of the entire module as a result.

The end result - you tell me... have you encountered a similiar experience?

Being Systematic to achieve results

Pondering about how well projects are managed by non-project managers (those without any formal training in project management) makes me think that it is time to get back to basics. Time to revert to being systematic about applying project management practices in order to achieve results.

I'm referring to the purposeful execution of project methodologies such as

• risk identification and review meetings
• stakeholder communication meetings
• schedule planning and review meetings

as deemed applicable according to the right methodologies determined to be beneficial to the project. My suspicions are that the non-project manager is more susceptible to loosing out on the benefits derived by applying these methodologies if their execution are left to chance.

I am speaking from a gut feeling when I say this. Always wondering how to best advise the non-project manager on the right application of the methodologies without them feeling like it is an unnecessary burden or bureaucratic nightmare. What concerns me, and leads my thinking towards insisting on a more rigorous approach, are three things:

1. Lack of formal risk management activities
2. Fits and spurts of planned activities
3. Under utilized team members

The problem is how to influence those in charge of projects to adopt a more rigorous approach.