Project Management Blog

Project Management and Templates

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:

dritter_2001@yahoo.com

October 23, 2008 Posted by Donna Ritter | PMP | | No Comments Yet

Potential Fraud may be happening to you in your everyday Life!

I have been going over our bank statements with a fine tooth comb to see where we are spending our money (which all of you probably already do  and have found charges that I didn’t make. I got either the bank or company to refund the charges. This week I had one for $143.40! I called the company and asked how they get my name to charge. She said whenever you get a magazine subscription on line or lots of other on-line activities they automatically charge you this *and* it is a revolving charge not a one time charge. They happily are refunding me but knowing that happens will give me some extra time each week to check the accounts. 

One time I caught one and called them and they said they wouldn’t take it off because I was over the 30 day limit! I had them transfer me 5 times until I got someone high enough to refund my money. I’m sure this is some kind of fraud but I’m not sure who to report it to. If any of you do, please tell me.

 The other place where I have had fraudulent charges show up is on my phone bill, AT&T won’t do anything about it but give you the number. I asked to have nu number blocked and they said they couldn’t. I am very close to dropping AT&T but we have 2 year contracts on 4 cell phones and I don’t want to be charged for that if I switch over.

 Warn your friends. I’ll bet I’ve paid these guys lots of money before I started scrutinizing my bank accounts so closely.

September 28, 2009 Posted by Donna Ritter | Family | | No Comments Yet

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 (Bill McKinney) Receives change requests
Project Core Team (Bill McKinney) Performs preliminary evaluation
Project Sponsors (Todd Coates) Final authority to approve a change for implementation

August 28, 2009 Posted by Donna Ritter | PMP, Project Initiation, Scope Management | | No Comments Yet

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.

August 20, 2009 Posted by Donna Ritter | PMP, Project Initiation, Project Management | | No Comments Yet

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.

August 19, 2009 Posted by Donna Ritter | PMP, Phase Review Process, Project Management | | 3 Comments

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.

July 15, 2009 Posted by Donna Ritter | Business Analyst, PMI, PMO, PMP | , | No Comments Yet

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

June 11, 2009 Posted by Donna Ritter | Business Analyst, Living Your Best Life, Outsourcing, PMBOK, PMI, PMO, PMP, Phase Review Process, Project Initiation, Project Management, Risk Management, Schedule Management, Training, Writing and Documentaiton | | No Comments Yet

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

June 3, 2009 Posted by Donna Ritter | PMBOK, PMI, PMP, Project Management | | No Comments Yet

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.

May 28, 2009 Posted by Donna Ritter | Communications Management, PMBOK, PMI, PMO, Project Management, earned value | | No Comments Yet

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

May 18, 2009 Posted by Donna Ritter | Project Management | | 2 Comments

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!

May 10, 2009 Posted by Donna Ritter | Family, friends | | No Comments Yet