Monday, August 8, 2011
Article: When One Assumes
Monday, July 18, 2011
So Little Time, So Much To Do!
Tuesday, May 10, 2011
Did We Get Let Go of the People We Need?
To read the full article go to http://www.mutoperformancecorp.com/2010SurveyResults.htm
We welcome your comments. Join our blog!
Saturday, March 12, 2011
2010 RESULTS OF THE TOP 10 OBSTACLES TO PROJECT SUCCESS
1. Changes to Project Scope (scope creep) [Third year in a row!]
2. Resources are inadequate (excluding funding)
3. Insufficient time to complete the project
4. Critical requirements are unspecified or missing [Up four from last year!]
5. Inadequate project testing
6. Critical project tasks are delivered late
7. Key team members lack adequate authority
8. The Project Sponsor is unavailable to approve strategic decisions
9. Insufficient project funding [Down two from last year!]
10. Key team members lack critical skills
Read the first article on our findings here;
http://www.mutoperformancecorp.com/2010SurveyResults.htm
Individual obstacles, trends in ranking, regional and industry based differences are just a few of the subjects we will cover in future articles.
Feel free to comment!
Thanks!
The MüTō Team
Wednesday, May 6, 2009
So Little Time, So Much To Do!
And now, we bring you the most recently disquieting subject of a Challenging Schedule!
One of the interesting changes between last year’s survey and this year’s, is the movement in the obstacle we know as the challenging schedule. In 2008, our respondents claimed it as obstacle #8, this year over 78% of our respondents voted it obstacle #2!
There may be many reasons why this obstacle is critical for most of our respondents, and some may seem obvious. Project managers are feeling the pressure to finish projects on-time, but by and large, they feel the time allotted is insufficient.
There’s only one true definition to this obstacle and that is that the date for delivery of the project’s solution makes it difficult to deliver on time. By definition however, according to any reasonable project process, the date of delivery of a project is a function of the project’s planning process.
Sounds good. This may have been the case last year, but this year, our respondents are claiming that the date of a delivery of a project is actually a requirement instead!
Comment away!
Tuesday, April 7, 2009
2009 Results of the Top 10 Obstacles to Project Success
#1: Changes to project scope (scope creep) Same as last year!
#2: Insufficient time to complete the project (up from #8 last year!)
#3: Resources are inadequate (excluding funding)
#4: Inadequate project testing
#5: Critical project tasks are delivered late
#6: Key team members lack adequate authority
#7: Insufficient project funding
#8: Critical requirements are unspecified or missing (down from #2 last year!)
#9: Key team members lack critical skills
#10: Project sponsor is unavailable to approve strategic decisions (down from #3 last year!)
We've had some interesting changes between the 2008 and 2009 surveys. Obstacles such as the Challenging Schedule, Invisible Requirements, and most notably, The Disappearing Sponsor have moved in their ranking.
What do you think causes these obstacles? What are some potential solutions?
Upcoming blogs; We have interesting information to share about how the obstacles were ranked by individuals from different regions of the world, early detection symptoms, and mitigation strategies.
We want to hear from you feel free to comment!
Wednesday, April 1, 2009
The Top 10 Obstacles to Project Success!
MüTō compiled the answers and identified ten frequent themes. We labeled these, the "Top Ten Obstacles to Project Success":
#10. A skill set challenged team
#9. Delegated responsibility unrelated to authority
#8. Challenging schedule
#7. Minimal or non-existent testing
#6. Tardy delivery of project tasks
#5. The resource challenge
#4. The finance challenge
#3. A disappearing sponsor
#2. Invisible requirements
#1. Spontaneous requirements
This year we thought we would take a different tack. Based on your experience, we would like you to rank the frequency of each of the "Top Ten Obstacles to Project Success." Click the link below to take our three minute on-line survey.
After April 1st we'll report the findings to you. We will invite you to join us in our ongoing discussions as we examine each obstacle separately. We'll be discussing the reality of how each obstacle manifests, talk about the early detection of their symptoms, as well as discuss potential mitigation.
The emails will be supported by a blog-spot for you to post your own impressions. The best thing about this is...ITS ALL FREE!
We appreciate your time, and look forward to your participation!
Just click on the following link at start your survey!
http://www.surveymonkey.com/s.aspx?sm=EivPdlXieQPtydoU8o2tjg_3d_3d
Tuesday, January 6, 2009
Managing Teams...I thought I had it figured out!
Team work...we know it takes this to accomplish work and drive the organization to success, day after day. And to make it work, we keep things straight, we communicate, we mentor, we give them opportunities, we keep the expectations realistic, address negativity and reward sucess (this is only indicative of the diverse things that go to manage teams).
And yet, I have came face to face with a member who disagree with his reward and position in the team. And where no level of persuasion or real talk makes a difference to the member's point of view. And this has its downside effect for the team. My question then is: Is this inevitable? Or am I missing something here that I could have done? And what could be done once such a situation comes to fore? I solicit your perspective on this.
MüTō Response:
You are not alone, and you are not missing anything. Based on your description, you are more advanced than many managers, especially in the concept of 'rewards'. Lets call it motivational management.
I wonder, do you really know the individual that is complaining. It appears that this individual is not 'happy' with the reward he has reveived for a job well done. If so, the question I have is was the reward an appropriate one for him? You see, motivation comes in many colors, shapes, and sizes. What works for one individual, does not work for another. Often times we as managers make the mistake of attempting to motivate our associates with rewards that are generic across the board. This is easy for us, we do one thing, and it should reward everyone! (coffee cards, bowling, pizza party, donuts...etc.)
Well, what happens if there's that one person who doesn't drink coffee, or hates bowling shoes, or is adverse to pizza, or cannot eat donuts? In fact it could be said, we De-Motivated them. That's a terrific problem, isn't it. Here we are doing the right thing....and someone gets pissed off.
Instead, what if we took a little longer just to get to know the people that work for us. We might find that the bowling party is not the best thing to do. Instead, it might be a half day next Friday.
The point is...this way, we would know and we could positively motivate our employees, and not fall into the accident of demotivating.
But there's more. You mentioned the individual does not agree with his position on the team. This cannot be helped...or can it? Lets assume it cannot. ie: You have no choice, the person took a job, and now does not want to do it, and feels he should be promoted.
This is a serious issue. This person wants something that will not happen. At this point a seious roles and responsibility conversation must be undertaken. The team member must be contracted to his job.
If they refuse to do it, what is the option? As a Manager, we must always face the fact that we may have to let people go. This is an example of one. Instead, what if the situation is, the individual is unhappy with his personal situation?
Well, that's a coaching opportunity. We should remember that one of our jobs as managers is to see our teammates grow. We have to be there to support growth. Perhaps its time for this individual to grow out of his position into some other position, department, or company. That's a good thing, not a bad thing.
In any case, I would recommend a strong sense of accountability when discussing these topics with the individual. Its not persuasion that will win the day, its the fact that you will have to hold this individual accountable for whatever agreements you strike up. As you must with all your teammates.
This alone will keep your team solid, and will put you in the best position to be accountable to them for their growth, and progress. Hope that helps!
Lou G
Sunday, November 16, 2008
On The Life-Cycle
Manager of Operations Date Center; Communication Company
The projects that success does not have, in its great majority had not had in its phase of elaboration the development and correct preparation. Before any beginning, all the factors must be considered:
- Time
- Cost
- Resources
In the computer science industry, generally it has two types of boardings comumente used in the management of projects. The boardings of “the traditional” type identify a sequência of steps to be completed. These boardings contrast with the known boarding as agile development of software, where the project is seen as a set of small tasks, instead of a complete process. The objective of this boarding is to reduce to the possible minimum overhead. This boarding is sufficient controversa, especially in very complex projects. Exactly thus, it has conquered adepts in increasing numbers.
In the last few decades, they had in general emerged a series of boardings in the industry. Amongst these boardings if it detaches the boarding of the PMBOK, that if has become a standard of fact in diverse industries
In the traditional boarding, we distinguish five groups from processes in the development of a
project:
Initiation
Planning
Execution
Monitoramento and Controle
Closing
Nor all the projects go to follow all these periods of training, since projects can be locked up before its conclusion. Perhaps some projects do not have planning or monitoramento. Some projects will pass for periods of training 2, 3 and 4 multiple times.
The project or enterprise above aims at the satisfaction of a necessity or chance, defined in the text as initial phase in which many involved areas and/or people exist. In general always it exists more than a solution or alternatives to take care of to the same necessities. The used technique to define the final solution passes for the development of extreme alternatives. The first one of low cost that takes care of the minimum necessities to be functional. Second it tries to take care of most of the requirements of the diverse involved areas in the target that results in a project with bigger and very little competitive cost. From both the alternatives are developed an intermediate solution between the same ones, that it takes care of to a good part of the requirements with a competitive cost.
Some sectors use variations of these periods of training. For example, in the civil construction, the projects typically progress of periods of training as Daily pay-planning for Conceptual Design, schematical Design, Design of development, construction of drawings (or contract documents), and administration of construction. Although the names differ from industry for industry, the real periods of training typically follow the common steps to the resolution of problems (they problem solving): to define the problem, to balance options, to choose a way, implementation and evaluation.
The management of projects tries to acquire control on three 0 variable:
time
cost
target
Some literatures define as four 0 variable, being quality the fourth 0 variable, however the quality is one of the main components of the target. These 0 variable can be given by external or internal customers. (S) the value (you are) of the remaining 0 variable is/is in charge of the manager of the project, ideally based in solids estimate techniques. The final results must be waked up in a negotiation process enter the management of the project and the customer. Generally, the values in time terms, cost, quality and target are defined by contract.
To keep the control on the project of the beginning to the end, a manager of projects uses several techniques, amongst which if they detach:
Planning of project
Analysis of aggregate value
Management of project risks
Cronograma
Improvement of process
MüTō Observation:
There is no doubt that the life-cycle decided for a project is tantamount to its success.
What we find is that Project Managers must have specific skills, that pre-date an understanding of process. The basic capability to Communicate, the ability to Motivate others, and the ability to hold project members accountable.
These skills are fundamental to project success. Without them...any process will fail. Guaranteed.
Sunday, November 9, 2008
The Project Itself...
IT executive: International commercial firm
The project itself.......
MüTō Observation:
This is funny. But not far from where most Project Managers stand. I have heard a lot along these lines whenever Project Managers say things like "This project is screwed up." or "We don't have enough money." or, "The sponsors are crazy." etc.
Its funny to them, until they realize its their responsibility to communicate, motivate, and hold the project parties accountable for their specific areas of success.
Sunday, October 26, 2008
On Requirements and Estimates
Technology Management; Technology Infrastructure
I agree that most project has some unique obstabcles, all project that i have worked with or been aware of have had 3 common problems
1. Incomplete requirements or lack of visibility to full requirements
2. Poor estimation of effort
3. Scope creep
MüTō Observation:
These are three very common problems. I often find that a project manager's inability to communicate clearly, encourage proper motivation, and hold others accountable is at the core of all three of the problems you listed.
Sunday, October 12, 2008
On Champions
Manager; Ebusiness Applications
I have found that for a PM and a project in general to be successful, the project needs a dedicated champion from the business side. If this Champion cannot be 100% behind the project, and does not have the authority or capability to make key decisions when issues come up, the PM will be a lame sitting duck and the project suffer cost overruns and delays.
MüTō Observation:
Its the Project Manager's responsibility to see to it that the Champion stay's focused, and accountable.
Sunday, September 28, 2008
On Project Stake Holders
“What obstacles do project managers face to successful completion of an Information Technology project?”
Manager MIS; National Social Group
I observed and experienced following factors based on my experience as PM in IT and non IT industry:
- Lake of interest of second tier stake holders
- Lake of understanding the importance of project by some major project stake holders
- Environmental motivation factor for project team
- Limited vision of Project Manager
- Without involving influential stake holders into the project proceedings
- Try to implement the project as a whole instead of module
MüTō Observation:
These obstacles can be mitigated through the basic ability of a Project Manager to communicate clearly.
For example, how can a 'second tier stake-holder' be considered important, if they have a lack of interest in the project? A PM can hold them accountable. If a Major Stakeholder lacks the understanding of the importance of a project, then it is the PM's responsibility to make certain they clearly understand it.
A PM's ability to motivate their project team is tantamount to the project's success. I agree. Their vision, and ability to communicate it holds a project together, and gets the project team to the next level of focus, and energy.
Sunday, September 21, 2008
On Clarity
Information Technology and Services Professional: Healthcare
“1. Management not setting a clear goal and openly, honestly communicating this goal to all, and providing their support to the project.
2. Poor communication at various levels throughout the project, including not properly identifying all the stakeholders.
3. Unrealistic expectations and finger pointing.
4. Addressing each project as though it was the first one ever undertaken; each project is seen as an "exception to the rules", therefore no consistent process can be put into place.
5. Personal accountability hard to find.
6. People not being held responsible for their actions/inactions.
7. Conflicting priorities and an unreasonable rush to start coding
8. Staff not honestly invested in the project management process -- including management. Often lip-service is given, but off stage everyone tries to bypass project management.
9. Overbearing project management processes that are more about the process (religion) of project management rather than focused on steps that add (or reasonably could add) value.
10. Projects begun as a management directive instead of agreed-upon as a project that is of value (resulting in little user buy-in and often result in treating symptoms instead of fundamental problems). Any ROI is done while the project is underway, and is totally subjective and based on management directive rather an an objective analysis/review.”
MüTō Observation:
I completely agree with your 10 points! Further, I'll add that they can be referenced into three fundamental abilities of a project manager.
The short of it is;
Imagine the Project Manager that could communicate clearly, and guide a sponsor to open/honest conversation on the projects' goals, attaining their complete support. This same PM could completely understand the various parties involved to be certain they are a complete list of suppliers, stakeholders, and beneficiaries. Expectations would be normalized, and finger-pointing would be eliminated. Process would become secondary to the project's success, but intently adhered to!
Now let’s make that PM able to motivate the project team to such a point that the project is their primary objective! (Not just their day job.) When priorities threaten to conflict, a team-mate would think 'first' of the project; Opening the door to accountability.
This same PM might also be able to hold parties accountable for their specific tasks/milestones/responsibilities.
Tuesday, June 3, 2008
On Project Control and a PM's Authority
Independent Financial Services Professional
“In order to ensure the Project Manager's control over a project, he/she should, at a minimum, have the authority to own one side of the project management triangle i.e. if any two are altered, for example, Scope and Resources, the PM has the liberty to adjust the third (delivery timeline) accordingly or if the delivery timeline is shortened, the PM should have the authority to reduce scope or add more resources to the project.
It is essential that there is a clear understanding and communication of which side is owned by the PM in order to ensure success.
This may seem very basic, but more often than not, projects fail because businesses make changes to one or two sides of the triangle, and expect the others to remain unchanged.
In order to track and measure these changes, a robust change management process needs to be in place backed by an effective communication methodology which ensures that all stakeholders are aware of the change, its impact, associated risks and have signed it off.
So, in order to ensure the success of a project, the PM should, at the outset clearly establish and communicate which part of the triangle he or she owns.”
MüTō Observation:
To a project manager, the topic that you framed can be summarized as "Lack of authority."
I completely agree with your summation, to paraphrase "clearly communicate authority" as being a responsibility of the PM. However, we are rarely in a situation where the sponsor/beneficiary or suppliers actually understand the Resource/Scope/Timeline relationship.
So in reality, it is pragmatic to presume that the state of the project in its infancy is that these elements are not understood, and should therefore be an educational topic up front in the project, And then a topic for reinforcement throughout the project.
This places the PM in a state of 'authority' that is stronger than any expressed authority, as it is an acceptable perception of leadership.
Just imagine, the Project Manager that clearly communicates authority throughout the project, and has an expressed managed level of comfort over "the triangle".
That's only the beginning.
Governance and Decision Makers
MBA
“- IT Strategy/Business Strategy Integration (Governance)
- Resource Management (dynamic workforce variation mitigation)
- Availability to Project Charter Signees (decision maker involvement)
- Vendors”
MüTō Observation:
Lets boil these obstacles to three elements; The PM's ability to clearly communicate, his/her ability to properly motivate team members to an active goal, and his/her ability to hold parties accountable for their tasks.
And that doesn't mean someone giving them the authority.
Very few organizations I have been through (most of the fortune 500) have effective project governance for more than I would call one management season (before rotation occurs at senior levels)...so that one season is just the environment. It impacts the PM when they need more money...so, at a lower level sponsors can be present. That requires more PM communicate-ability.
Resource management is a bear (especially with outsourcing/offshoring so prevalent.) The dynamic nature of today's workforce literally means your assets go away. So what keeps them at a firm? What if a PM could supercharge his team into believing in the project? (I say that's the PM's responsibility.) It would certainly reduce the dynamics...but it would require a heck of a lot of work from the PM.
Availability of the Charter signers is not too problematic...people sign stuff almost naturally in the corporate world, BUT...holding them accountable! ha! That's a different story. That's the involvement part, eh? Can a PM get an answer/decision from the 'decision maker'? That's a problem...one that requires the PM to hold the chain above him/her accountable.
And finally, Vendors....I assume you are talking about them holding to milestones, or over-promising capabilities, etc. That's the trick. Holding them accountable is also a bear, but something a PM can do a lot easier than holding internal resources accountable. ("You don't deliver, we don't pay.") Still, Soprano tactics result in someone being bumped-off...not a good tactic when you need to complete a project. So, How does a PM hold a Vendor accountable?
That's a fundamental skill, and one I teach. It has to do with having a Plan "B" that everyone agrees on.
On Suppliers
Managing Director, Project Management Firm
“The biggest and most consistant problem we encounter is the failure of IT service providers (both local and iternational) to meet installation deadlines. These providers also have a habit insisting on ridiculously long lead times for installation of their services.
A good project manager can control most other issues with proper systems and planning."
MüTō Observation:
This is the classic issue. The question is at what point does the Project Manager realize this problem. Is it at the delivery date? Or at some point prior? A Project Manager that is holding his suppliers accountable will know well in advance that the service provider is going to have a problem meeting their deadlines.
Long lead times can be negotiated, once you take the time to pry them apart. “It is what it is” Is the easiest excuse to pry open, just try asking “And what exactly is it?” Approaching the ludicrous is a great way at finding out the underlying nature of the estimate. Are the suppliers simply building in “Buffer time” or have they REALLY figured out how long the task will take?