What activities do you consider intangible like ad hoc meetings that don’t make it to the project plan?
Project Management: All activities great and small should be on the project plan.
Wikipedia search: In project management, a project task is an activity that needs to be accomplished within a defined period of time.
When I make proposals, they typically require a detailed project plan so that the client can either receive a fixed price or get an accurate estimate of resource requirements (time, money, and people).
More Wikipedia definitions: A project in business is typically defined as a collaborative enterprise, frequently involving research or design, that is carefully planned to achieve a particular aim. Projects can be further defined as temporary rather than permanent social systems that are constituted by teams within or across organizations to accomplish particular tasks under time constraints
Though you try very hard to predict what things might occur with time, money, and resources, it is not always possible. You should be able to compare the “not planned” to the “planned” activities (or tasks).
Ad Hoc meetings are a project task that consumes project resources. They should be project tasks on the project plan even if they are in the past. They have taken project time, money, and resources.
Project Management is responsible for comparing planned and unplanned activities. Very small back to back ad hoc meetings consume precious time and people. Company cultures are made up of several fatal flaws that creates inefficiency and lack of accurate reporting with project plans leading to project failures:
1) Plan doesn’t show what actually happened.
What was reported?
Project manager tells the project champions what tasks are completed on the project plan.
What actually happened:
Project resources worked on other higher priority tasks and only worked on the documented tasks to avoid trouble. There was higher quality attention paid to the ad hoc activities than to the tasks on the project plan.
Some symptoms and author comments:
Every week the project manager reports that the project is either a green or red light. The project is behind or the project is ontime. It is good or it is bad or it is almost good or it is almost bad. blah blah blah
And you executives don’t want to hear any bad news…You beat up the messenger if they report bad news or “rock the boat”. Are you listening to me? Do you want to succeed? Or perhaps, do you want to fail?
The project tasks are completed according to the dates and the tasks given in the project plan. I am not gonna tell you about the rest. Time allotted doesn’t allow it. Or the project champion doesn’t want to hear the details.
The team has completed the tasks or has them 80% complete….Unfortunately, it has been 80% complete for six weeks but we have absorbed more resource costs trying to work on the other 20%.
All of these reporting statements tell this author that the project could be in trouble. And unfortunately, these items are usually organizational versus actual software issues.
2) Progress is reported on only tasks put into the plan at the beginning of the project or tasks that were “approved”.
Some of the same as number one but a lack of reporting occurred on resource consumption for other tasks not on the project plan.
Status reports showing other tasks should be produced in detail for work actually accomplished or meetings actually attended regardless of whether it was on the project plan. NO GENERIC CATEGORY CATCH ALLS please.
We “project planners” that have never done a Product Hub implementation before combined with MDM Product Generalist consultants designed a project plan that should work perfectly for an off the shelf PIM Data Hub implementation and integration, right? WRONG! You are dead wrong and you are allowing a text book author to practice theory on a very specific task. You’ve proven the need for product MDM and you’ve already selected the software solution. Now, please let the practicioners help you build a project plan that is realistic and adjustable.
3) Ad Hoc project tasks happened.
What happened and sometimes Why?
You didn’t put tasks into the project plan that were necessary OR you didn’t put tasks into the project plan because you used people to help you that have never implemented.
You changed your business requirements as you understood the MDM purposes and methodologies. You clarified your scope after you launch your project.
You didn’t pull your internal resources into the project at full committment and now they are balancing priorities chaotically. You didn’t reserve them appropriately.
You haven’t empowered the right internal resources to the project so the ones you are using have to schedule an appointment/meating to get permission to do everything. Uhhggg!!
You spent all your time and money finding a solution but no time estimating the level of committment internally that it is going to take to finish the job.
You let your generalists run the project with no oversight from MDM software specialists.
Business analysts should know the software before they are qualified to gather lower level design requirements. Therefore, you should start gathering them when you start the implementation.
4) Project plan is so unrealistic that project resources redirect to what they think should be done.
Do you think that this won’t happen?
You have really good internal resources that know you like a book. They know what you reward and what you punish.
They know what they think or what they have been exposed to. They believe that they need to change the plan to make it better for the organization.
Buuuutttt, you punish changes and you punish learning organizational behavior.
Therefore, your very smart internal resources will report what you want to hear but will try their very best to make it successful without telling you what they had to do. Because if they do, you might offer advice that is perceived as an order. Or you will get angry or upset at them actually telling you that they are going to erase and start all over. Don’t get me wrong. I believe that you need to get the job done ontime and on budget. That is why I am stating all of these harsh realities up front. However, leadership can make it harder to change that it needs to be.
Great Project managers are heroes to me. I salute them. They do a job that no one else will do for less reward. Wow… We pay our program and project managers less than we pay the product experts and MDM generalists. This is as absurd as how we pay our public school teachers. An experience project manager who hasn’t checked in for psychiatric care or switched occupations is worth their weight in gold. It takes courage and very thick skin to do their jobs. Let them have some leeway with you on reporting their observations. Don’t kill the messenger!
5) Project plan doesn’t fit the company or consulting firm’s culture.
If you didn’t get the memo, then I feel for you. When you were growing up, did your parents ever tell you the “right tool for the right job”?
There is a heavy amount of change management required within most firms in most industries (including very big mega software companies..hint hint) to conduct a successful product MDM initiative. The enterprise must allow it to occur but also get into the design. This is NOT an IT project. This is a business driven project with heavy technical solutioning. Business must drive the design and keep it off the shelf at the same time. It extends the amount of learning required by important business process experts in your organization. See my 16weeks blog article for more.
A mechanic is not expected to be able to redesign an automobile’s engine. A painter is not supposed to create new paint formulas. An airline pilot doesn’t redesign the air traffic control system.
There are big contracting firms. There are big consulting firms. There are big MDM consulting firms. There are big Product MDM firms (maybe). There are small ones too (pick me…). You need to have someone other than a buyer to help you distinguish the difference. You are paying too much for implementation or too little if you pick the wrong implementation partner. I have got a lot of other articles on this topic alone because I have to compete with dishonest representation lately.
Choose your methodology well. You or your firm will design your project plan according to their priorities and their knowledge in the area. I have seen some firms actually take my project plan (not honestly take) and fail. Why? Because they didn’t know what to do within the tasks that I put into the project plan. They simply and blatantly copied it and sold their services as PIM implementation experts. When they typically were either generalists or developers, not anywhere in between. That is where implementors and project managers are, somewhere between theory and creation.
I can boast. I can design PIM Data Hub configurations off the shelf for any industry better than any other PIM implementation expert on the market today. I can design the PIM data hub better than you even if I don’t know your industry. What? Did I just say that? What I mean is, you cannot find someone with experience at your company doing PIM Implementation if you’ve never done it before. What you need is someone who has intense Oracle PIM experience that will guide you into being able to design it yourselves.
My PIM Developers get a higher market rate because they have been taught and exposed to some common technical and functional knowledge to compliment their years of Oracle Applications development. However, I would never risk moving them to functional roles without their committment to making the change. You can’t do both. Sorry, I don’t even want to speak to the exceptions to this rule. You are taking short cuts, my friend. Claim one or the other. Technofunctional is another word for a developer who is desiring a higher rate than someone who has no experience in the PIM Data Hub.
6) Any other reason that things should not be listed as tasks on a project plan that consume project resources that are already allocated.
Put all the tasks on the project plan. Even the ones that are now in the past. You need to see what you actually did on the project to better plan the future.
Rule of thumb: If the meeting has more than two people or lasts more than two hours, it is a project task. If it is a general purpose meeting scheduled weekly or daily, it is a project task. If you don’t like recording these tasks then why do you like having them?
These factors can lead to expensive project delays, reportable successes but unreported failures, and complete project failure.
I am thinking about creating a poll to see if any of this is true in the other current projects. This is a very controversial subject in the industry today. There are big firms offering to implement free as long as you keep them as your “one throat to choke”.
I will usually back off of bidding against these “unqualified” firms because the client has never taken a purchasing class in college/university. They don’t realize what selecting the “lowest cost provider” has in implications.
Have a good day and I hope you get some good information out of this very opinionated article.