Breaking Your Commitments
Categories:
Career Development
Categories: Career Development
| In my previous post, I talked about work commitments. Sometimes success in project delivery requires breaking those commitments if they are not in line with your goals. If you need to break a commitment, I recommend the following steps: 1. Identify a commitment you have made that is not benefiting the project. 2. Consult with the project manager and/or supervisor whether this activity can be removed from your list. 3. Identify someone suitable to deal with this task. Seek advice from your manager when in doubt. 4. Once you've secured management authorization, transfer the details of your commitment to that person. 5. Advise the person to whom you originally made the commitment that the task has been reassigned to another person, and explain the reason for this action. Depending on your role and authority, you may be able to deal directly with the person to whom you made the commitment, and you can resolve the conflict without involving other parties. There's no magic formula for undoing what's done. But by breaking such commitments in this professional manner, you are renegotiating the terms of your commitments and earning trust and credibility. |
Veering From the Typical Career Path
Categories:
Career Development
Categories: Career Development
| I recently watched a Hindi movie called 3 Idiots. The moral was to follow your passion--which got me thinking... In the software industry I've seen examples of technical leads who were promoted to project manager based on the assumption that they'll perform just as well in that role. But in several of these cases the technical lead has failed in the new position. That's because project management is not about resolving technical issues. It has other parts: resource management, cost management, expectation management, etc. Companies shouldn't automatically follow the standard growth path for each role, whether it's for a software engineer, senior software engineer, technical lead or project manager. Rather, the path should be decided based upon an individual's capability and interests. A technical lead may be interested in business analyst work or quality-assurance activities instead of the project management role. Also, as individuals we should have the opportunity to follow our passion and not feel tied to a typical career path. What do you suggest? |
Is This Your Project Stakeholder--The Conclusion
| My last post received a wide range of comments and I wanted to draw some conclusions based on those comments and my thoughts. The majority of those that left a response said they would choose "option one." If you selected "option one" and well managed your relationship development and engagement processes, then helping "Mary"--the stakeholder in question--and her team contribute to the change should be beneficial. Why? The first thing to consider is that Mary would be a key stakeholder at several different levels in the overall change management program. As a long-term employee leading a group of workers, she is a stakeholder in the overall organization and is likely to have many unofficial contacts and significant influence. As the leader of a group of workers who will be disadvantaged by a planned reorganization, she and her team are critically important stakeholders for the change manager. The group will never like the consequences of the change, but they need to be included so they at least cooperate for the good of the overall organization. Because they can contribute knowledge and support, Mary and her team are also stakeholders of the program and particularly your project. The assumption that your team has enough knowledge to bypass her people is risky. You don't know everything that happens in Mary's section on a day-to-day basis. The second important consideration is where the value is created. Ultimately, there is no value to the organization unless the change is successfully implemented. Your project may deliver a key component needed for the reorganization but if it is not used, there is no value. This is something IT people in particular need to remember; 99 percent of IT projects require changes to business processes and are a complete waste of time if the business people reject the new processes. If you selected "option two" and chose to ignore Mary, she is likely to become an active opponent of the change (no involvement equals no commitment and no support). This puts your most important stakeholder at a disadvantage: the overall change manager. |
A PMBOK® Guide for the Trenches
| When you are introduced into a project environment, with a team who has never used project management and knows little of it, what is going to help most? Is A Guide to the Project Management Body of Knowledge (PMBOK® Guide) too airy and sophisticated? Put another way, if you find yourself in a World War I-era trench, which would you rather have: the operator's manual on your howitzer or The Art of War by Sun Tzu? Over my next few posts, I want to introduce my own version of the PMBOK® Guide, unencumbered by peer review (or even consistency). It will give me a chance to cut through some of the academic cobwebs that may have set into our practices, and illuminate recent issues and problems. We'll start with scope. Scope: (noun) the output or outcome for which your customer is willing to pay. You've probably already recognized that, by this definition, the customer can't request anything out of scope, since what they desire is, by definition, in scope. And you would be correct. So, if you don't want to find yourself in a situation where your (paying) customer is asking for more than you were originally willing to produce for a certain price, you had better have a very detailed agreement--otherwise, that most deadly of project ruination elements, scope creep, will devastate you, your team, your organization and your project. Here's further proof that my definition for scope is correct: If your customer wants to add work to your project and will to pay for it, what project manager would refuse to do it on the grounds that it wasn't in the original statement of work? No matter how absurdly the original work breakdown structure (WBS) was set up, if a person with sufficient organizational clout generated it, it can never be substantially changed. In fact, the very act of pointing out that a proposed WBS element is inappropriate is a serious career-limiting move, since everyone knows that the ability to create a valid WBS is the litmus test for real project managers and pretenders. I've found that the pretenders will attack any challenge with a ferocity rooted in their insecurity. Yes, it all begins with scope, but it obviously doesn't end there. Next up: schedule. |
Pick Your Commitments
| When we work on a project, we commit to tasks that work toward the grand result. You have these tasks because at some point in time in the past you have committed yourself to doing them. Taking on many commitments can make you feel powerful at times, but not delivering on the expected result is a total loss of that power. Here are some tips for managing your commitments: 1. Get really clear on the particular project requirements and what role you play. 2. Clear your plate of any commitments that do not contribute to the project's end goal. 3.Commit to your role within the project. 4. Commit to the number one task: always delivering on your commitment. 5. Ask yourself daily: What did I commit to doing today? Am I in a position to deliver on those commitments? It's best to break a commitment ahead of time--leaving you free to execute exactly what you need to be doing. How do you manage to commit only to what you know you need to achieve? In the future I will discuss more about how to break commitments not in line with your goals. |
