Project Management Blog

With the current economic conditions, an increasing number of people are either afraid of losing their jobs or desperately searching for work. Just like it’s a buyer’s market for housing, it also seems to be a buyer’s market for employers. Those who are hiring can be extremely selective in whom they choose. That’s why smart Project Managers plan today for tomorrow’s “what if.” We need to be smart about managing our own career “risks” and have a mitigation plan firmly in place now. There are three simple, cheap, and super smart things you can start doing now to avoid any unneeded worry and panic if you do, in fact, find yourself looking for other career opportunities.

1. Invest in yourself. First, make time to invest in yourself. No more excuses! If you do not currently have your PMP® certification, now is the time. You don’t have to spend a lot of money. A PMP exam prep course can range from about $800 for a PMI® chapter sponsored course up to $3,000 for a professional training course. All told, your total required investment is small compared to the rewards (significantly better pay and more visibility as a job candidate). Further, if your current company pays for training, you really have no excuse; that’s a benefit you can’t afford to pass up. Nothing in life is guaranteed, and that includes the job you have today. Take the time to invest in your career now, so you do not end up having to scramble if things take a turn for the worse.

If you already have PMP certification, look into some advanced training that is complementary to project management. There are a number of niche areas that employers are starting to look for (i.e. Six Sigma, ITIL, CMMI, Agile/Scrum, etc.). There is a strong emphasis on “doing more with less” these days, and employers are looking for people who can help improve how they run as a business. Broaden your skills, and differentiate yourself by being a project manager who understands the world outside of just managing projects.

2. Create a buzz. Now is the to start making a name for yourself! Start a course of action to position yourself as an expert in your field. One way to create a buzz is to write articles on what you know. You can do this a number of ways. First, try submitting articles to your local chapter of PMI or another local professional organization. Groups like this are always looking for new content and will often be more than happy to publish your work in an online newsletter.

Another way to get your ideas out there is to start a blog (or post here!). Also, WordPress offers free blogs that take only a few minutes to set up. You can write as often or as little as you like. Write about whatever you are passionate about, and you may be surprised at how many readers you end up with!

Consider joining a local Toastmasters club in your area. If you’re feeling adventurous, book a speaking engagement or two! This will provide you with credibility in your industry, and you will undoubtedly become a better speaker as a result. Plus, it’s a great way to meet influential people in your industry.

Demonstrating your communication skills, both written and verbal, is a good way to make you a better project manager and get the word out that you are an expert in your field. Start building your reputation by putting your thoughts and ideas out there.

3. Make a difference. If you are busy making a positive difference in this world, you will be rewarded. Volunteer your time! If you are not doing so already, get involved as a volunteer with your local PMI chapter, or work with another non-profit organization in your area. By giving of your time and talents, you will likely find you get tremendous satisfaction in mentoring others around you. You will also strengthen your own skills and maybe even pick up a few new ones. It’s also another great way to meet good people in your area. I personally know a lot of people who have found wonderful new jobs as a result of becoming a volunteer. Make a difference in the lives of others, and your life will positively benefit as well.

If you focus on developing these three areas, you will undoubtedly have an amazing road ahead of you, both personally and professionally, regardless of the ups and downs of our economy.

Erika Flora, PMP, ITIL Expert
Principal Consultant, Beyond20
erika.flora@GoBeyond20.com
http://blog.erikaflora.com

1. Poor planning:
Who are your IT managers and do they get enough opportunity to plan or under pressure from senior management they tend to think planning as a waste of time because they believe that time is better spent doing something rather than planning. Do you involve your project team in planning? Do they have the skills and experience to make complete plans? Or you always ask them to implement the solution. These are fundamental questions that need to be answered first.

2. Unclear goals and objectives:
Many IT projects are elaborated progressively and in these scenarios project managers rely on rolling wave planning. As a result, the goal of a project may be only partially clear due to a poor requirement gathering in the definition stage of the project. In such case, the scope and schedule developed by project managers cannot possibly be accurate because their objectives are unclear. Defining clear requirements for a project can take time and lots of communication.

3. Poor Stakeholder Management:
Project stakeholders’ interests may be positively or negatively impacted by the project and that is why stakeholders’ influence on the project is the most important thing to consider. Stakeholders who are found later will make changes and could cause delays. Any change that is made later is harder to integrate and is much more costly.

4. Scope creep and Feature creep due to objectives changing during the project :
Uncontrolled and unexpected changes in user /stakeholder expectations and requirements as a project progress always negatively impact a project. This is known as scope creep. Many times new features are added to the project with a wrong assumption that one small feature will add nothing to cost or schedule. This unplanned addition is called feature creep.

5. Unrealistic time or resource estimates:
Many times project managers make costly mistakes while estimating time or resources. One common mistake is made during the creation of the Work Breakdown Structure. Often it is assumed that the time on task equals duration. Project managers estimate the time on task is the time the task will take to complete. How about interruptions? Some may be known and some may be unknown. Do project managers anticipate interruptions? In reality duration is the time the task actually takes to complete including interruptions.
Another common problem is using linear approximation when estimating the schedule For example, if you double the number of developers, you can cut the project time in half. In reality, doubling the number of developers produces a non-linear result.

6. Improper delegation of task and responsibilities:
Many times project managers fail to delegate tasks and responsibilities to the team in such a way that they should fit team members' job descriptions. When team members are asked to work outside their specialization (often as added responsibilities), they not only go through a learning curve but also tend to lose focus on the project objectives. This always results in confusion among the team members and eventually cost and time overruns.

7. Lack of executive support and user involvement:
IT managers face many difficulties in managing projects and the lack of executive support and user involvement are the two main reasons of IT project failures. Many times IT project managers work as project coordinators or project expediters and without executive support they cannot personally make and enforce decisions. The second reason is user involvement and often the project planners fail to plan human solutions to the very human users that the product is proposed to serve.
8. Failure to communicate and act as a team:

Projects sometimes fail due to improper communication. Many large IT projects are so complex that these projects always require large amount of analysis and work. The project teams are busy doing the analysis, creating WBS, time estimation etc. and project managers do not communicate progress regularly because they believe that progress will not be seen by the executive management or they fear of improper reporting.

9. Lack of proper risk management:
Another potential cause for project failure is the IT managers’ inability to categorize all the risks qualitatively and quantitatively and implement corrective measures.

10. Inappropriate skills:
The rapid changes of the technology-driven business environment and the constant changes of technology make it hard to predict skills the IT department will be needed.
Almost all large IT projects require a diverse range of skills. Many teams lack the breadth, and depth they require. Also dearth of qualified people in the labor market and high attrition rate of the industry add many problems to the projects. Often, projects mangers spend substantial amount of their time in recruitment related activities.

Project Management is perhaps one of the most fiercely debated and grossly misunderstood disciplines in the software field currently, hence let me throw in a disclaimer first: if you are a small team of experts and/or people well-known to each other (e.g., have worked together as a team earlier), and situated in a collocated fashion, doing a lot of ‘creative work’ that can’t be very ‘accurately’ scoped, let alone managed; you probably will find ideas of formal project management a huge overkill (on time, effort, money and might even seem to stifle creativity), and you might be better off considering ‘lightweight’ methods like Agile Project Management / Scrum in the context of software development (well, nothing stops you from deploying pieces of Agile / Scrum in a non-software context – it is based on common sense after all). Small projects, small teams can afford to define a process that exploits the tailwind:

- A small and collocated team means more direct interaction among team members and lesser management overheads in formalizing project communication (e.g., project status reporting, team meetings, etc.). This reduces the time it takes to collate, transmit and share important project information and also decreases the possibility of information distortion or confusion. A small team means there is high signal to noise ratio in team communications, is also leads to a better utilization of time spent in transmissing, receiving or digesting communication. Further, to schedule any event, one can always convene impromptu meetings around a whiteboard or around the coffee table without worrying about people’s already double-booked calendars or finding a place large enough to fit the team for the next meeting, and so on.

- Having a group of experts means there is low(er) need for managerial supervision and people are generally ‘hand-picked’ for their knowledge, skills and abilities that could typically be ‘mutually exclusive, collectively exhaustive’. This ensures tight interdepency and very high mutual respect among team members. There is lesser ‘competition’ among team members and everyone knows that “united we stand, divided we fall” which fosters teambuilding.

- For a small project, a large swing in any of the project constraints (time, cost, scope) could seriously and irretrievably impact the project in a downward spiral. If the work is new to the team, it could spell bigger trouble, especially if there is no way to do mid-course corrections. Executing projects in an iterative fashion helps shorten the feedback loop and give a chance to make necessary corrections to improve its ability to stay on-course and eventually hit the target. Additionally, if there is a customer involvement on these short iterations, the quality and value of these feedbacks could improve substantially lest any decisions are made that are hard to change if required.

However, if your project is anything more than a handful of people, takes more than a few months and entails issues like external dependencies with multiple vendors and ISVs (Independent Software Vendors), substantial technical and managerial risks, subcontracting / co-development, etc., you probably might improve chances of success using a formal project management methodology like PMBoK or PRINCE2 than without it. Agilists will argue and disagree with me that Agile / Scrum is not suited for large projects, but if you are new to Agile as well as to large projects, you might want to consider all options and associated risks – don’t believe in what worked for others, it might or might not work for you (remember the golden rule – we are all different), and your company might have a different set of constraints and tolerance to performance.

The size, complexity, criticality, and risk profile of a project, and organizational appetite for project risk and uncertainty, and organizational culture would generally determine the level and need of management control required, and hence one must always right-size the project management methodology based on the context. Both, PMBoK / PRINCE2 and Agile methods evolved in response to challenges seen in executing projects successfully. While PMBoK / PRINCE2 took the approach that projects most often failed due to lack right levels of management oversight, planning, execution and control; Agillists felt the key reason was the fundamental nature of software being a ‘wicked problem‘ that just could not be managed using an obsolete waterfall model of developing software - it needed a better way to develop software in short iterations with very close-knit self-managed teams.

Without getting my loyalties needlessly divided betwen the two of these approaches, I believe there are merits in both the thoughts. I refuse to believe that any non-trivial project can be managed by piecemeal iterations that give no commitment whatsoever on the overall project performance, nor give any method to assess if the overall project is indeed on the right track (so, even if first few iterations are achieving the desired ‘veolcity’, what is the guarantee that subsequent iterations will also move at the same pace?). On the other hand, doing an iterative development is highly intiutive and very effective way to learn from past experiences to plan next steps, especilly on any non-routine project that is full of unknowns and assumptions. To me, these represent ‘mix-and-match’ ideas that one should pick up and apply wherever required, without getting baptized to the school of thought. I find most process wars have taken the disproportionate dimensions of falling just short of religious wars – you have to belong to one of the camps, and must talk evil about the other camp to be seen as a law-abiding corporate citizen of that camp. In life, we borrow ideas around us – our housing society, professional volunteer society we volunteer for, our kids playground, gardening, home improvement, nature, science, religion, other cultures…without necessarily converting to another faith or religion or society just because we like an idea that we want to borrow. So why should that be required in project management methods ???

I think this process war will be won by pragmatics. Those who take a position on extreme ends of the continuum and insist on always applying a particular style as the panacea might be in for a complete surprise because no two problems were created equal. A prudent approach is to evaluate all options and then decide which is the best response to a problem, as opposed to blindly follow a project management approach ‘religiously’.

Do you follow your project management aproach ‘religiously’ ?

[From my blog Manage Well, http://managewell.net]