• Posted on February 26, 2013 10:29 pm
    By admin
    admin
    No comments

    The life cycle methodology is one of the most efficient paths you can take for your business opportunity to follow. This methodology is useful in the business world because of its nature. It deploys the most efficient means for a project manager to initiate, plan, execute, and conclude a project plan so a revenue stream can be established by an organization. The path the life cycle methodology follows begins with the initiation phase. This is where the business plan and feasibility study are conducted to see if the business opportunity will be of a benefit to your organization. There is no need to go further with a project if the profit potential of the opportunity does not meet the goals and scope of the stakeholders. This phase is also the foundation on which your project will be established.

    What is Project Management
  • Posted on December 9, 2012 3:11 am
    By admin
    admin
    No comments

    You didn't really become a project manager because you wanted to work for a living, did you? I get hives just thinking about it. The PM is there to make sure the screws get turned in the right direction at the right time, not to actually turn them. Start turning them yourself and you could (sorry, I can’t resist) screw things up. Of course, you became a PM because you love making things happen and you find it rewarding to assume responsibility for things. And you want to do a good job or you wouldn’t be among the two or three people reading the blog this quarter. This conscientiousness makes it difficult for you to keep your hands out of the cookie batter, especially if you’re new to the role or things are going south. The problem with is, once you start mucking around in other people’s business, you run a handsome risk of flinging muck everywhere and gumming up your project. When a PM gets involved in the day to day work that rightfully belongs to resource managers and their resources, communications get crossed up and relationships get cracked. Why might this happen? And what happens if it does? Expert Syndrome. You’re an expert! You came into project management from a more task-focused field and you’re used to getting in there and doing, not making sure other people are pitching in. So, you start in to work, or more likely—and worse—you try to micro-manage the people practicing in your knowledge area. Folks get resentful, their tolerance quickly gets to zero and pretty soon nobody is telling you anything you need to know because they’re afraid that if they talk to you, they’ll invite further interference or finally give in to the impulse to wring your neck. Relationships are the PM’s most precious, useful resource—handle with care. Manager Guilt. More common in new PMs, this is the feeling that you’re not really contributing because you’re not writing code or making a CAD drawing or whatever. You stick your nose in, much like the Expert Syndrome PM, only your attitude is… well, kind of pathetic. You end up not only annoying people, but making it obvious you don’t believe in yourself or your role. If you don’t believe in the value of the PM’s function, your team won’t either. You’re the One. You believe that if you want something done right, you've got to do it yourself. This is great if you’re one person responsible for a single task area on a project, but if you’re managing the whole thing, what are you going to do? Do all the jobs yourself? Of course you can’t, so you’re going to walk around wishing you could. Take this approach and you’re going to wear yourself down to a nub with worry, and pretty quickly. Projects are hard enough without a freaked-out PM. Make the leap of faith and believe in your team. If you really believe some of the team can’t cut it, go talk to those resource managers Now. How do you avoid the causes of doing actual work? Change Your Mind. The causes I've outlined above are all more or less related to your emotions and/or your belief system, so the first thing you want to do is change those. You can do it—after all, you chose them. If you’re not sure how to go about it, try engaging a business coach for a few sessions, or read a couple of books. The One-Minute Manager is a good start, even if it is an oversimplification. Neal Whitten’s No-Nonsense Advice for Successful Projects is a great in-depth coverage of just about everything you need to know to achieve project management fame and fortune. Get With the PM Program. If you’ve got enough time to run around doing work that’s not related to project management, you’re not doing enough of your project management stuff. Go back to the PMBOK guide, or the training materials you used to get your PMP certification, or to a more experienced PM, and figure out what you could be doing that you’re not. Oh, and if you haven’t had any project management training, go get some. There are loads of degrees and programs around, and your company might even foot the bill. Next: Warm, Fuzzy, and Feudal: Relationships and Project Management

    Change Management, What is Project Management
  • Posted on December 9, 2012 2:00 am
    By admin
    admin
    No comments

    Once upon a time, when I was still a pretty new project manager, I got assigned a dotted-lined reporting relationship to someone other than my usual program manager. The project was a big one, in terms of both dollars and prestige, and the guy was nervous. All to often, we’d have conversations like this: Mr. Nervous: “Have you done anything about risk management?” he would say. Nev: “Yep. Here’s the risk log from yesterday’s team meeting.” Mr. Nervous: “Why isn’t it longer? You’re obviously overlooking things!” Nev: “Um… But the team only identified…” Mr. Nervous: “Team shmeam! Find the rest of ‘em!” We did this a lot. It was never fun, and he was never satisfied, at least until we delivered, which we did, well within time, budget and quality measures… in spite of the fact that we got blindsided a couple of times. Yes. Blindsided. Hosed by unforeseen gremlins lurking in the woodwork. We had a good list, but it wasn’t quite complete. The worst part of it was Mr. Nervous’s I-told-you-so look, which alternated with his panicked look (not much of a treat, either). The whole experience got me interested in risk management. If 90% of a PM’s job is communication, then the other 90% is risk management. So for the next few entries, that’s what I want to talk about. If you do this well, in a way you can articulate to others, not only can you mellow out the Mr. Nervous’s in your life, you can save yourself an ulcer or two.   Next: Risk Identification, Part 1

    What is Project Management
  • Posted on December 9, 2012 1:17 am
    By admin
    admin
    No comments

    It occurs to me that after my waxing philosophical and getting all academic about communication planning, some of you might want to know what deliverables you might actually have to come up with. Fair enough, but be careful what you wish for… it can be a lot of stuff, if you go whole-hog with it. Which of the following items you use depends on theneeds of your project and the standards of your organization; likewise, their precise form. Here we go: Setup Deliverables: Project charter: The document that defines the limits of the product—scope, timing, budget, etc.—at a middling-to-high level. Project budget: How much you’re going to spend, on what, when, and the total thereof. Project plan: Your detailed task list and timeline, possibly accompanied by a work breakdown structure diagram. Project resource plan: Your team roster, also including the resource managers of those on your team. Reporting Deliverables: Weekly status report: Shows if the project is green (just fine), yellow (having temporary troubles), or red (in serious jeopardy, probably in need of executive intervention). Provides detail on accomplishments and troubles. Shows at what point the project is in the life cycle. Monthly status report: Like the weekly, but with less detail; intended for executives. You might try to create a scorecard for this report, with metrics, targets and variances. One-off reports/presentations: These are usually used to explain why the project is in yellow or red status. Logs: Risk log: Identifies risks, how likely they are to occur, what impact they’d have if they did occur and what the mitigation plan is. Issues log: If an identified or unidentified risk comes to fruition, it becomes an issue. This log identifies the issues, their impacts, their owners, plans to resolve them, and the status of those plans. Action items log: Identifies tasks to be accomplished in the near future, who is responsible for completion, and the status. This can be used as a supplement to the project plan or as a record for tasks that are too small or too rapid to fit sensibly into the project plan. If you are very clever, you will think of a way to cross-reference between items on the AI log and items in the project plan. Meetings: Meeting schedule: Simply a list of meetings for the project and when they’ll occur. Includes recurring meetings and gets updated with one-offs. You might use a calendar management application like Microsoft Outlook for this. Meeting agendas: A full-blown agenda states when and where the meeting is, who should be there, what the overall topic is, what the goal is, and the topics to be discussed, in order. You won’t always need a list of topics; sometimes something like “discuss router disaster and resolution” is all you need. Meeting minutes: Minutes record when and where the meeting was, who attended (as opposed to who should have been there), the overall topic, highlights of the discussion (including action items completed), conclusions reached, new issues uncovered and action items assigned. Informal Communications: (These aren't exactly deliverables, but they're still important!) Email: All those quick messages novel-length threads are a major part of the oil that makes a project go smoothly. Don’t write anything you wouldn’t want on the front page the next day. File emails logically for easy retrieval. Keep everything; you never know when you’ll have to show why a decision was made or that so-and-so did, indeed, promise to deliver by November 2nd. Conversations: Like email, conversations on the phone or in the hallway, grease the skids of your project. While they are great for exchanging information, avoid making any commitments during an informal conversation—save that for a more formal setting. And if you’re talking to the client, be discrete; tell them what they need to know, but don’t lift up the sheets of your operation. Some clients will use extra info about your operations to squeeze you, or to go around you, or in other unhappy ways. Balance: Eighty to ninety percent of your job as a project manager is communication, so it can be easy to go overboard. Work on striking the balance between too little and too much information. Note: Writing this blog is a learning exercise for me, as much as anything else. In researching this post, I learned a lot from www.my-project-management-expert.com. Many thanks to them.

    What is Project Management