What does that 'PMP' behind your name mean?
The Project Management Institute has set standards for people to become certified Project Management Professionals. It is something like becoming a CPA. The standards require basic education and a demonstration of your knowledge in the form of a test. One must renew the certification every three years, which involves continuing education and retesting.
I am proudly a naturally born Citizen of the United States. That means I can work for any company in the USA.
I prefer a team environment where I can help others to succeed and advance. I learned several years ago that I do not want to be indispensable.
I was managing projects before I knew there was such a thing as a project manager or that one could be formally trained for it.
On one of my last assignments, I was given a project to implement electronic funds transfer (EFT) to pay healthcare providers for their covered services.
The project was originally grossly underestimated at 2,700 hours and didn't even include an estimate from the most impacted department. By the time all players were identified and on-board, the project required 30 change controls and finished at 13,900 hours.
The letters of praise that you see on my "praise" page are the result of this project.
Before I started at VISA, I didn't know there were formal methodologies, so I had to develop my own methodology for project management. It was similar to what the PMI developed, but not as structured.
At VISA they had a proprietary methodology, similar to the PMI, but with a greater emphasis, and more structure, on testing and QA. Using it, we did a Y2K remediation on the off-line credit card system, which consisted of over 9,000,000 lines of assembler code.
At IBM, we used several methodologies:
At BCBSSC they have a proprietary methodology based on the PMI but customized for their corporate structure and geared towards application development and remediation.
"That's not my job."
When there is a problem, it's MY problem. I'll deal with the appropriate team member(s) individually and not in public.
When there is praise to be given, John or Mary deserves it. I may have facilitated the work, but he or she did it.
For planning, I am expert in both Microsoft Project and NIKU Workbench. I prefer Project and have taught it before.
Additionally, I developed my own Access database that I use to track issues, risks, changes, etc. I am expert in Microsoft Word, Excel, PowerPoint, and Visio.
If Lotus Notes is available, I am also a trained database developer as well as email user.
I used to love sailing on our sailboat. I also love photography and gardening (except on the bottom of the boat). I sell things on eBay occasionally. I develop web sites for friends and groups.
The company lost some contracts and there was not enough work left to do.
Frankly, one of my least favorite things to do is to watch the clock. I'd much rather see the job get done than to worry about how many hours it took to do it. If 5:00 rolls around and I'm in the middle of something, I keep going. I also frequently take work home with me, if possible.
I am a big believer in work-life balance, so I try to make sure that people are not over-scheduled and are free to enjoy their families and hobbies. However, there are times when going above-and-beyond is necessary and I will try to help them understand why. If they buy into the reasons, they are less likely to resist and resent it.
Yes, I want to work. I will listen to all proposals for anywhere in the world, just so long as it is legal (and safe) for an American to work there.
It's pretty simple. I know what I made last year. I check the cost of living and adjust my income to match.
Sorry, but no. They have been the proprietary intellectual property of the respective customer/employer. Even if I had copies, I would be breaking the law to give them to you.
All the parts are important, but the most "visible" part is communication. All stakeholders need to know where the project stands, what's going on, and how they need to be involved. This can be both formal and informal. Obviously, a status meeting and report (usually weekly) are pretty much standard items everywhere.
I find it more reassuring to most stakeholders to spend time personally with them. If it is possible to be face-to-face, I prefer that, otherwise the phone is useful.
In addition to status, everyone needs to have the same expectations of the finished product. The earlier conflicting assumptions are brought in line, the better for everyone, even if that means closing the project.
The process is slightly different everywhere I go, but it generally follows these steps:
The first thing I do is to ensure that I fully understand the requested change and its impact. I then write up the request and discuss it with the requester, especially if the impact is significant.
Then I have the Change Control Board (CCB) review the request and determine if it should proceed. I will generally agree with the CCB, but the final decision is mine. After the CCB has accepted (hopefully) the change, I take it to management (in the prescribed format) for approval.
After management has approved it, I return to the customer/sponsor, who will be paying for it, and seek formal approval to proceed. If there are date, cost, or manpower changes, I thoroughly review these so that everyone understands the impact.
After that, I formally adjust the project plan to include the changes and re-baseline the affected activities. Then the change is communicated as widely as needed and tracked through its completion.
Generally, dealing with management. I believe that management deserves and needs frequent status and I endeavor to do that. However, there are times when they ask too much for me to get the rest of my job done. Yes, management needs to be informed when issues arise, especially those that need escalation, and when changes are requested.
First, I am a firm believer that everyone needs to be constantly aware of project risks and communicating them to the whole team.
Usually I am responsible for the first round of risk identification. I share these with the team so that we can all determine if the probability and impacts are correct and that the mitigation strategies are adequate. The team then gives me more risks and we discuss them before including them in the list. If the team seems to not know how to identify and quantify risk, I will hold one or more sessions to help them learn.
I occasionally bring out the list and review it with the team to make sure it's current and reflects reality.
On nearly every project I've done I have had to manage diverse groups, usually including upwards in the organization. For example, the data center consolidation that is mentioned in my resume:
I developed the original idea, pitched it to my manager, who liked the idea of saving lots of money. He gave me some tips on selling it to higher management. I put together an executive presentation and sold them on the idea. However, they decided, for political reasons, that someone from that data center should manage the project.
The person who was chosen did not keep the project on track, so I had to step in and assist him. His boss realized what was going on and asked that I be made the sole PM. Between the two of us, we convinced corporate management that it was a good idea.
Using the refinery (the remote data center) maintenance schedule as well as the technical requirements, I put together a schedule and budget to complete the project. This required keeping in touch with the maintenance managers as well as the executives to both get and give status and keep them on board with the project.
The real crux of the project, however, was not the technical aspects. The biggest problem was assuring the people (union and non-union) who worked in that data center that their jobs were not in jeopardy. I am proud to say that only one person (of the 20 some) left the company, but he had been looking before this project started.
On conversion day, as scheduled, I packed the back up tapes, boarded the company plane and had the data center operating again on the main computer, before the sun rose. There were no glitches and the end-users started calling to ask why everything was running so much better all of a sudden.
Vendors are one of the diverse groups of people who need to be managed. If we are installing a vendor's package, I expect a knowledgeable representative of that vendor to be on-site (if we are on the bleeding edge), or available by phone (for more established products).
I find it rather annoying if that representative is not fully competent with their product. If they tell me "No one ever asked me that before..." or "I have to call someone else" to answer every question, I will call the vendor management and request a more knowledgeable person be assigned.
This is not a single question, despite what it looks like.
The first question that you should seriously ask yourself, before you ask me, is, "Do you really want the project saved?" How did it get out of control? Someone didn't do their job right - and that wasn't necessarily the current (or previous) project manager. Was it properly estimated? Was it properly funded/staffed? Did the requirements change without filing change control documents? Was it simply doomed from the beginning by imperfect procedures, expectations, or oversight?
Now, onto the next question, what do you mean "out of control?" Is it over budget? If so, why? Is it understaffed? If so, why? Is it unlikely to meet its deadline? If so, why and is it even possible now to meet it?
Now, my answer to the original question is, if it is possible and you will do whatever it takes, yes, I can save it. Responsibility, accountability, and AUTHORITY must all be given together - they cannot be separated.