Announcement
I am avaliable for training people on Project Management with the express outcome of passing the PMP. Please contact me if you are interested:
Change Mangement Items to Add to Project Plan
1 Project Change Management Plan
1.1 Change Management Approach
Every project experiences change. If change is not formally managed, there is little likelihood that a project will be completed on time and within budget. Change can affect a project’s scope, cost, quality, risk, schedule, and work products, as well as the functioning of the project team.
The IT Monitoring & Enterprise Alert – Recommend Architecture & Tools Project will adopt a collaborative change management approach emphasizing an understanding and agreement among all parties about what the project changes are and how they will be managed.
When the project team needs to determine whether there is a change, the baseline documents are always the reference point. The baseline document for this phase of the project will be this document, the “Project Definition” document. Anything that is not covered in the baseline or that alters the baseline is a change. The process allows for change during the project life cycle, but puts the change in the context of the latest documented agreement.
1.2 Types of Change
Change will be classified as either design change or non-discretionary change. Non-discretionary change results from a failure of someone to do what he/she previously committed to, or the failure of some previously planned event to occur, and is sometimes tracked as lost time. A design change is an enhancement/correction to the system after initial specifications have been approved.
1.3 Change Budget
The purpose of the change budget is to provide an appropriation (of dollars and/or hours) that a project can draw from when change is encountered. The Project Team manages the change budget, providing approval for change expenditures when a change is approved or denying change expenditures when a change is deferred or rejected.
1.4 Change Management Process
The project team will manage changes by using the process described in this subsection.
1.4.1 Submit Change Request
Any team member may submit a written change request to the Project Manager.
1.4.2 Perform a Preliminary Evaluation
The Project Manager reviews each change request and determines whether to defer, reject, or accept the change. If the change is accepted, the Project Manager estimates the effort to perform the impact analysis. Because an impact analysis of significant effort can cause a change to the current project schedule and/or budget, the client must decide whether to move to impact analysis.
1.4.3 Analyze Impact
If the change is to undergo an impact analysis, the Project Manager will assign the change request to a project team member. For our project, simple technical implementation, the technical team assumes responsibility for the impact analysis and involves additional technical staff as necessary.
The assigned resource(s) and the Project Manager first review the estimate for the effort of the impact analysis, and then work together to determine the effort, cost, schedule, and resources needed to implement the proposed change.
1.4.4 Review and Implement the Change
The Project Manager submits the impact analysis report to Project Sponsors for review.
¨ If the change is approved, the appropriate processes are followed to update the work plan, project documents, and the change is implemented.
¨ If the change is rejected, the Project Manager logs the decision and reason and closes the change request.
¨ If the change is deferred, the date for the next review is set.
1.5 Roles for Change Management
| Role (Contact Name) | Role |
| Project Manager | Receives change requests |
| Project Core Team | Performs preliminary evaluation |
| Project Sponsors | Final authority to approve a change for implementation |
Starting the Project out Right
First – make sure all stakeholders are at the first meeting. Also ask the Project Sponsor to tell everyone you are the Project Manager (transferring authority). Talk about the processes you will use and the communication everyone can excpect from you.
Once you have a definitive scope, write a requriements document to meet that scope and distriubute it and sign it off. After this point, any change in scope should go through your defined scope mamangement process.
Do your schedule as a team and construct a Work Breakdown Structure. Break each task down until it is no more than 40 hours or less. Add them back up to get the schedule. If management doesn’t want the date you’ve come up with ask them which scope they want to drop. Remind them that each feature takes time from you (as PM), the coder, the tester, the documenter and suppport.
As you move from requirements to specifications and coding, adding scope is even more costly. It disrupts everyone. Try to put it in a subsequent release.
Above all, make sure you communicate schedule, risks and status very frequently; and hopefully have a team site on SharePoint that everyone can see.
Scope Creep
People have asked me how to stop scopr creep. The way I do it is to have a change review board that every scope change must go through to be reviewd. That usually stops the managers from adding scope since I ask theym to sign off on the change management board in the beginning.
The decond problem id when and engineer wants to add scope on his own. To stop that, I have team members put in their time daily and their remaining time to get a task done. That helps me to find potential scope creep.
It is also vital to explain the whole process to the team and stakeholders. No one really wants the projct to fail and when they realize the impact of adding a little code enhancement to the testing and documentation groups, they tend to stay away from it.
That being said, it is a #1 problem in Project Management. Just keep on top of the project at all times.
How to Write a Business Case
Most of us have had to write a Return on Investment or a Business Case for projects we have worked on. The purpose of these documents is to define the overall benefits and costs of a project at a very high level usually aimed at Project Sponsors. The document allows you to provide much more diligence on the costs and benefits, while still not requiring you to actually go through the effort of specifying the work at this time. All Software Projects go through iterations of detail definition as more is known about the project. They key is to set the expectation of the degree of schedule confidence at each level of specification. At the Business Case Level the confidence in the schedule is very low.
When the Business Case is accepted by the Project Sponsor it is time to write a Project Charter and Project Scope Document which can be used to finalize the Project Plan and Work Breakdown Structure. It is ideal to have the project team identified once the Business Case is accepted. If not, it is vital to have the majority of them identified by the time you finalize the Project Plan, Work Breakdown Structure and Schedule.A feasibility study is used to provide much more diligence and understanding about whether the project is feasible or not. In fact, the feasibility study might be a project in itself. The study might just be a more detailed analysis of the viability of a project and may not require a small project structure.
The result of the feasibility study is a document that is also called a Feasibility Study. There are a number of areas of feasibility that should be analyzed.
- Technical. Is the project technically feasible? If it is you should state any technical risks associates with the project.
- Financial. Is the project financially feasible? This would be especially important if the cost of the project was material to your company. It is possible that a project could have a cost that is significant enough to put the entire company at risk. You may have the ability to budget for the project now, but you might also analyze what the impact would be of a significant cost overrun.
- Operational. You should make sure that you have the ability to run the products that are built by the project. It is possible that the project itself is feasible, but you may have significant risk in being able to operate the product after the project is over.
- Geographic. Is the project feasible given the physical location of the project team?
- Time. Is the project feasible given the amount of time it will require from the participants? This is a big worry on larger projects. You may have the budget to execute the project but you may realize you cannot free up the project team for enough time to execute the project. .
- Resource. Do you have the staff, equipment, supplies and other resources necessary to complete the project?
- Cost/benefit analysis (high level). You still have to complete the cost/benefit analysis as a part of the feasibility study.
- Recommendations. The conclusions and recommendations should be noted. One technique that can be used is to look at a number of alternatives for how the project should progress (if at all). For each alternative discuss the benefits, costs and risks. This will show the reader that the right level of diligence was performed and that a number of alternatives were considered. Your final recommendation should address assumptions, risks, ROI (return on investment), estimated cost (with a confidence factor that is fairly low), priority and next steps to be performed.
All of this information provides further detail on the nature of your study and provides your management stakeholders with the complete set of information they need to make the best decision on how to proceed.
Linkedin Profile
Check out my Linkdin Profile at www.linkedin.com/in/dritter5! I’d love to hear your comments on what services you would like provided.
Donna
Ways to remain calm during the PMP test
Make sure you have studied a lot. The test is a 4 hour multiple choice test that is randomly selected from PMI’s test base. Bring energy bars and water. They won’t let you take anything in, but will give you a locker to store your stuff. Take a break at least once an hour to stretch your legs, take a snack and break. This clears your head.
When you first get in the testing center, they give you paper and pencil. The first part of the test is a tutorial on how to take the test. Take this time to do a brain dump of all the formulas, knowlege areas and procces groups. The questions are very situational, so you can usually emliminate 2 answers quickly. If you are not sure, mark the question (it lets you do that to come back to it) and go on. Also, somethims questions further on into the test will help answer an earler question. Aim for 30 minutes for looking at the questions you didn’t feel sure about and to review your exam. THen as soo as you push the confirtm question, it will take a few minutes to grade (a long few minutes) but it will help a lot. I wasn’t sure I passed – but I made a 98%! Keep you PMP certifcation eu to date and you’ll never have to take the test again. When I took it, the rule was you had to get 60 PDUs in 3 years. You can get some from training or some from running projects, reading a new PM theory book and other things. Look on PMP.ORG to find out the requirements to keep your PMP certication. And get a good nights rest and calm yourself. No one knows what you make and I think they give you 2 or 3 times to pass.
Have a great day!
Donna
The Nature of Project Management
Why do many talented developers and IT professionals consider project management to be an obstacle, rather than an enabler? Why do clients often resist project oversight or try to minimize it? Does project management really allow projects to reach completion more quickly, or are speed and project discipline mutually exclusive?
We’ve explored the balance of speed and delivery and the nature of innovative projects in recent articles. Let’s tie these themes together and review techniques that help keep project management relevant to even the most unique and innovative programs.
Project bureaucrats
When I teach project management, I often draw a distinction between project managers and project bureaucrats. We’ve all had encounters with project managers who turned into bureaucrats. Project bureaucrats are more interested in ensuring that every step of the methodology is applied and every line of every form is filled in than in what’s actually happening on the ground. On the other hand, it’s common to meet project managers who apply minimal project methodology, yet, through their expert use of relationships and personal interactions, always seem to know exactly where the project stands.
In my experience, it’s the project bureaucrats who often leave a bitter taste with both the delivery team and the client. These project managers turned bureaucrats have forgotten one of the key rules of project management: don’t mistake the map for the journey. All the plans, charts, and milestones mean nothing if they aren’t consistent with the reality on the ground. And there’s the rub; especially in innovative projects, the plans and estimates are often based on a fallacy — there’s the idea that we can predict the progress of something that’s never been done before.
Project spec compliance = success? Not always
In his outstanding book Agile Project Management, Jim Highsmith offers two examples that emphasize the point. The movie Titanic, from a project management perspective, was a huge failure — over budget, over schedule, and plagued by unforeseen risks that threatened to derail the project at every turn. Motorola’s Iridium project, which spent billions of dollars launching satellites into orbit in order to make telephone service available worldwide, was a great project management success. Yet the market is the ultimate judge, and the project management compliance of Motorola’s venture didn’t save the project from failure, nor did the project management disaster (no pun intended) of Titanic’s production taint the film’s appeal to the public.
The lesson that project managers should learn from these examples is that compliance with project specifications does not constitute project success; in the ultimate analysis, only business results matter. Stated another way, the largest risk in any project is not that it will deviate from plan; it’s the risk that the final outcome won’t fulfill the real need. Predictive methodologies, such as the techniques championed by the Project Management Institute in its PM Body of Knowledge, can add tremendous value, especially for projects for which we have a historical basis to look to for precedent. For truly innovative projects, in which any prediction is little more than guesswork and for which we’ll be inventing never-before-seen products, we need to look for a new approach. Hence, the growing popularity of agile approaches.
Agile myths and truths
The central insight of agile methods is not that project overhead is a pain in the neck or that programmers like to be free; instead, it is the observable truth that, especially in innovative programs, customers can’t describe what they want until they see it, and prediction is inappropriate when there’s no way to visualize what the final result will be, let alone exactly how long it will take to build.
Unlike predictive methods, in which the planning, estimating, and risk assessment activities are all front-loaded and often are seen as a separate “planning” phase, agile approaches assume that the requirements will grow incrementally and iteratively as the project proceeds. This emphasis on “just enough” planning and requirements discovery is an acknowledgement of the fact that the key up-front activity in an agile approach is the creation of the first iteration of the product, so that the sponsor can see it and touch it, and discrepancies between the sponsor’s vision and the product created by the team can be modified to fulfill the current business need.
Agile project management is often misunderstood, as illustrated by the proliferation of articles about “agile myths.” Agile methods are not about “buying pizza and getting out of the way,” as these methods are often caricatured. Agile methods, from SCRUM to Highsmith’s APM Framework, are disciplined and structured approaches to product development, just as predictive methods are; these methods just address different types of problems.
Predictive and agile approaches have robust requirements discovery techniques, but agile methods acknowledge that requirements will evolve throughout the life of the project rather than up-front. Both approaches have stakeholder participation practices, but agile methods insist that stakeholders and sponsors are involved throughout the project in a collaborative, interactive manner. Predictive and agile both have mechanisms for integrating changing requirements into the plan, but the approaches use different techniques. Predictive techniques often apply restrictive change management procedures. Agile methods are specifically designed to encourage and implement beneficial change by providing an iterative, incremental approach to development focused on implementing, rather than controlling, positive change.
Innovative projects call for innovative methods, but that doesn’t imply, as many agile skeptics insist, that the benefits gained by applying structured project management techniques must be abandoned. Agile approaches are appropriate for creative, inventive projects because the methods integrate exploratory, collaborative techniques into the project process and acknowledge the mutating nature of exploratory IT projects into the PM methods we apply. Even PMI, in its newly published Body of Knowledge, recognizes the value of the iterative, incremental approaches advocated by agile proponents.
More to come
In subsequent columns, we’ll dig a bit deeper into the specifics of some of these techniques and explore ways that agile approaches can be combined with familiar, predictive techniques to apply exactly the right level of rigor to the project, no matter where it falls on the innovation spectrum.
Get weekly PM tips in your inbox
TechRepublic’s IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!
Rick Freedman is the author of three books on IT consulting, including “The IT Consultant”. Rick is a Director in the Global Services Division of NEC America, and a trainer and course developer in the Agile Project Management practice of ESI, the international PM training company.
2009 Results of the Top 10 obstacles to Project Success
- Scope Creep
- Challenging Schedule
- Resource Challenge
- Minimal or non-existent testing
- Tardy Delivery of Project Tasks
- Delegated Responsibility Unrelated to Authority
- Finance Challenge
- Invisible Requirements
- Skill set Challenged Team
- The Disappearing Sponsor
Happy Mother’s Day!!
Celebrating motherhood is a historical tradition dating back almost as far as mothers themselves. A number of ancient cultures paid tribute to mothers as goddesses, including the ancient Greeks, who celebrated Rhea, the mother of all gods. The ancient Romans also honored their mother goddess, Cybele, in a notoriously rowdy springtime celebration and the Celtic Pagans marked the coming of spring with a fertility celebration linking their goddess Brigid together with the first milk of the ewes.
During the 17th century, those living on the British isles initiated a religious celebration of motherhood, called Mothering Sunday, which was held on the forth Sunday during the Lenten season. This holiday featured the reunification of mothers and their children, separated when working class families had to send off their young children to be employed as house servants. On Mothering Sunday, the child servants were allowed to return home for the day to visit with their parents. The holiday’s popularity faded in the 19th century, only to be reincarnated during World War II when U.S. servicemen reintroduced the sentimental (and commercial) aspects of the celebration American counterpart.
In the aftermath of World War I, Washington D.C. resident Grace Darling Seibold formed an organization called Gold Star Mothers, to support the moms who had lost sons and daughters to the war. Grace’s son, First Lieutenant George Vaughn Seybold, was an aviator who had been killed in combat over France in 1918.
In 1928, the small D.C.-based group decided to nationalize its efforts. The Gold Star Mothers grew from a support group of 60 women to an extensive nation-wide network with tens of thousands of members and hundreds of local chapters. Today, any American woman who has lost a child in the line of duty can join the Gold Star Mothers.
The organization’s primary role then and now is to provide emotional support to bereaved mothers. Members also actively volunteer with the veteran community and act as patriotic supporters of the United States military.
In 1936, a Joint Congressional resolution established the last Sunday in September as Gold Star Mother’s Day, a holiday that has been observed ever since by Presidential proclamation.
Early in President George W. Bush’s tenure as president, he renewed that proclamation, declaring on September 28, 2001:
“Today, the nation’s Gold Star Mothers still stand as symbols of purpose, perseverance, and grace in the face of personal tragedy. Each year, the Nation remembers their sacrifice by honoring the Gold Star Mothers for their steadfast commitment to the legacy of their fallen children and their devotion to the United States of America.”
The name the Gold Star Mothers was derived from the custom of military families to hang a service flag in their front window. The flag featured a star for each member of the family serving in the military; living members were denoted in blue, while gold stars honored family members killed in the line of duty.
Happy Mother’s Day to all Moms – You are Awesome!
Do you know what it means to miss New Orleans?
|
you’ve never heard of a dry county.
you don’t know what a county is. when you hear gambling is illegal in some other states and are surprised. you know the 12 Yats of Christmas by heart. you know what Schwegman’s is. when you know what “LAGNIAPPE” and “LAISSEZ LE BON TEMPS ROULER” mean. when you go away for college, and when you tell people where you’re from they automatically know you can drink more than everyone at the school put together u tried “cajun” food somewhere else and u thought it tasted like shit You reinforce your attic to store Mardi Gras beads. Your sunglasses fog up when you step outside. When you give directions you use “lakeside and riverside” not north & south. Your ancestors are buried above the ground. You get on a green streetcar to go to the park and a red one to the French Quarter. You take a bite of five-alarm chili and reach for the Tabasco. You don’t learn until high school that Mardi Gras is not a national You push little old ladies out of the way to catch Mardi Gras beads. Little old ladies push YOU out of the way to catch Mardi Gras beads. You leave a parade with footprints on your hands. You believe that purple, green, and gold look good together. Your last name isn’t pronounced the way it’s spelled. you get aggrevated when 1. people think mardi gras takes place in the french quarter and 2. that people think that no matter what time of the year it is if they go to the french quarter they will get a boob shot! when you get pissed at people who pronounce it nawlins, norlens, or new or leans. You know what a nutria is but you still pick it to represent your baseball team. No matter where else you go in the world, you are always disappointed in the food. Your town is low on the education chart, high on the obesity chart and you don’t care because you’re No. 1 on the party chart. Your house payment is less than your utility bill. You don’t show your “pretties” during Mardi Gras. You know that Tchoupitoulas is a street and not a disease. Your grandparents are called “Maw-Maw” and “Paw-Paw.” Your Santa Claus rides an alligator and your favorite Saint is a football player. You cringe every time you hear an actor with a Southern or Cajun accent in a “New Orleans-based” movie or TV show. You have to reset your clocks after every thunderstorm. You’re walking in the French Quarter with a plastic cup of beer. When it starts to rain, you cover your beer instead of your head. You eat dinner out and spend the entire meal talking about all the other good places you’ve eaten. You actually get these jokes and pass them on to other friends from Louisiana. you know what is meant by ‘K&B purple You know what it means for food to come ‘dressed’… you ‘ax’ for things… you see a van taxi with spinners you know your from new orleans if you recognize at least one person in a parade You save newspapers, not for recycling but for tablecloths at crawfishboils when you travel abroad you always remember to pack 2 things: bottle of tabasco and a salt shaker of tony’s in your purse Drive-thru daquiris — it’s not drinking and driving until you put the straw in. You drive east to get to the West Bank. You stand on the neutral ground at parades and have no idea what a ‘median’ is. You get annoyed when you wear a Perlis shirt and people ask you if you work at Red Lobster. You know how to pronounce Mignon Faget. pulling a baby out of a cake is completely normal. you know McKenzie is both a football player and a landmark you made one bad turn and you end up on the twin span at least once. you know what the twin span is. you shop at Lakeside. you listen to people represent their ward on Q93. you know that the Riverwalk is for tourists. sock hops were cool in middle school (and not the 70s) AND you think its stupid when people ask you if you actually took your socks off. someone asks you for starbucks and you give them CCs or PJs you have waited in the ridiculously long line for Camellia Grill during lunch at least once. The only Bush you respect is a Black man. You refuse to believe that there is such a thing as the “Utah Jazz”. There is a color called “Bur-GUN-dee”. The concept of a basement never crossed your mind. You get your car’s suspension repaired at least twice a year. You know at least two best places for sno-balls. You’ve seen roaches bigger than rats. You’ve seen rats bigger than cats. the roof of your house was at sea level, and your stuff was at the “bottom of the sea” WHEN YOU DONT REFER ”MARDI GRAS” AS THE CARNIVAL…WHO SAYS THAT??? If someone in a Lowe’s store offers you assistance and they don’t work there, you may live in Louisiana If you’ve worn shorts and a parka at the same time, you may live in Louisiana If you’ve had a lengthy telephone conversation with someone who dialed a wrong number, you may live in Louisiana. If “Vacation” means going to Dallas for the weekend, If you measure distance in hours, you may live in Louisiana . If you know several people who have hit a deer more than once, you may live in Louisiana. If you install security lights on your house and garage, but leave both unlocked, you may live in Louisiana. If you carry jumper cables in your car and your wife knows how to use them , you may live in Louisiana. If the speed limit on the highway is 55 mph — you’re going 80 and everybody is passing you, you may live in Louisiana You know that there is one “Original Lee’s Hamburgers” even though they all say they are the one. If there’s a major hurricane headed straight for you and all you’re worried about is that they changed the time of the LSU game. |
-
Archives
- August 2009 (3)
- July 2009 (1)
- June 2009 (2)
- May 2009 (4)
- April 2009 (1)
- March 2009 (1)
- January 2009 (3)
- December 2008 (6)
- November 2008 (7)
- October 2008 (16)
- September 2008 (24)
-
Categories
- Business Analyst
- Communications Management
- earned value
- Family
- friends
- Glossary
- Hurricanes
- Jesus
- knowledge areas
- Living Your Best Life
- Outsourcing
- Performance Management
- Phase Review Process
- PMBOK
- PMI
- PMO
- PMP
- Project Initiation
- Project Management
- Project Phases
- quality management
- Risk Management
- Schedule Management
- Scope Management
- Training
- Uncategorized
- Writing and Documentaiton
- Young Life
-
RSS
Entries RSS
Comments RSS
Project Management 