In Part 2 of this three-part series we will look at further at Jason Chravat’s presentation of the attributes of a project manager from his book entitled “Project Management Nation: Tools, Techniques, and Goals for the New and Practicing IT Project Manager.”

In this segment, we’ll discuss the need for the project manager to have:

• General knowledge of project management
• Understanding of technology and some technical background
• Ability to work successfully as a problem resolution professional

These are just a few more of the key areas of expertise that the project manager needs to possess. Read on for further discussion.

Knowledge of Project Management

The first step for a newcomer to become qualified in project management is to complete a program of education. Meeting with others who are learning about project management is helpful, but it takes time. Alternatively, a prospective project manager can gather the information on his or her own. Those new to the profession don’t always need degree programs or pay large sums of money just to learn project management. Many of the world’s leading project managers learned their skills and techniques from experience and on-the-job training. That’s where the best secrets lie, and that’s why I thought sharing my experiences with project management would be helpful.

Technical Authority

Project managers often tell me that, as project managers, they do not need to understand the technology or technical issues because the technical resources working on the project will be responsible for the technical detail. Unfortunately, in the IT environment today, it is important for all project managers to be well-versed in the relevant project technology (including its applications and processes) and be able to communicate on technical issues with the “techies.” The majority of organizations that employ project managers insist that the project managers be able to take technical decisions and that they possess the necessary technical skill sets to be on a similar level as the technical staff.

I have heard many IT resources complain bitterly about project managers who haven’t got the foggiest notion of what needs to be done technically. The result is often that many of these resources simply carry on with their own development process and view the project manager only as an administrative manager who coordinates time sheets and ensures the delivery of status reports.

Project managers who are not well versed on the technical level find themselves (1) isolated, (2) lacking in credibility, (3) not consulted technically on major development issues, (4) not taken seriously, and (5) possibly even provided with false information. Project managers who understand the technology and can use it practically can apply such knowledge with outstanding results. Project managers also need to be certain that they have obtained the necessary project authority from the project sponsor and then communicate this to all stakeholders. This senior executive involvement often does the trick!

I always encourage project managers to make technical decisions if and when an opportunity arises, or to be involved in any way possible, by playing the role of facilitator or negotiator with the staff.

Sun Tsu said…

If the general’s employment of his mind is not in harmony with the army, even though the formation’s lightness and heaviness are correct, and the front and rear are appropriate, they will still not conquer the enemy.

Ability to Identify and Resolve Problems

Problems will arise on any project, no matter how much planning and effort have been made to avoid them. Recovering from any such problem means that the earlier the project manager can address the problems, the better. Identifying problems may require the project manager to review tasks with resources in order to find the real causes of these problems. If the causes are not within the manager’s own control or authority, then he or she must go to the project sponsor and seek advice there.

As alarming as this may seem, it may mean stopping the project until a solution is found, which is a good suggestion. Remember, the earlier you make the input to correct things, the smaller the input required.

Continuing to let tasks and milestones go off track will make it more difficult to correct the situation.

In Part 3, we’ll look at the project manager’s need for an ability to make timely and critical decisions, effectively select and manage a team of skilled resources, and to have a professional approach when dealing with management, teams, and the customer.

Related posts:

1. The Attributes of a Successful Project Manager – Part 3
2. Attributes of a Successful Project Manager – Part 1
3. Training the Client and Support Staff for Go-Live

Related posts brought to you by Yet Another Related Posts Plugin.

Each month the people at Project Management Tipoffs (brought to you by Arras People) review a book in the Project Management realm and post the review to their site. I’ve worked with them to bring their reviews to our readers as well. “Managing Project Uncertainty” by David Cleden, was the subject for their June 2009 review post.

According to their reviewer, this book is simple and useful to project managers in the way it breaks down and presents helpful PM information. Please read on…

Managing Project Uncertainty (by David Cleden)

Few quotes from Managing Project Uncertainty resonate nearly as well with the project manager as Field Marshal Helmuth von Moltke’s ‘No plan survives contact with the enemy’ (pg. 28). Author Cleden surmises that von Moltke’s statement ’sits at the heart of any strategy for managing uncertainty.’ In essence, Cleden is talking about projects as if he is talking about the future – no one knows what’s going to happen.

The book is simple in other ways, like breaking things down about project uncertainty in relatable and easily-understood ways. Many readers will find figures like the Four Quadrants model a useful tool in identifying what you do and don’t know. There are also useful tables, including the flawless Hallmarks of Effective Decision-Making, and the book’s focus on the types of variables involved in managing uncertainty is detailed, thorough and open. Most importantly, Cleden is successful in implying that uncertainty arises on the project scene because today’s static world (when the project is planned) will not remain so (when the project is being carried out). You know the London 2012 Olympics needs certain facilities; what you don’t know are the uncontrollable variables (Political? Economic? Environmental?) that are going to wreak havoc on the effective delivery of those facilities. Those who planned to sell their property within the last year that have been left wishing they’d acted a year earlier are nodding their heads right now.

Cleden will leave you with a sound understanding about the traits, tendencies, timing and tenacity of uncertainty in projects. He is also adept at identifying certain methods that try to contain the uncertainty, and why some prove more successful than others. Those who expect risk management to be the be-all, end-all for uncertainty solutions will be in for a rude awakening. While you can’t always anticipate uncertainty, let alone the ultimate degree of difficulty it creates in your project, you can adapt, especially in a world of cost-effective budget management. Moreover, it might also be – in addition to being a good alternative title – the best glass half-full way of approaching uncertainty: “Managing Project Adaptability.

More information and review text about Mr. Cleden’s book, as well ordering information, is available at Gower Publishing.

Related posts:

1. Book Review: Project Governance
2. Book Review – The Lazy Project Manager
3. Book review: PMP: Project Management Professional Exam Review Guide

Related posts brought to you by Yet Another Related Posts Plugin.

In school I hated to turn anything in misspelled or with handwriting that didn’t look how I wanted it to look. I took me a long time to ever start using pens because I always wanted to be able to erase and correct. Ok, I may have been a little OCD about that.

Even with my articles, I run them through spell checkers first – though that doesn’t catch a correctly spelled word that may be out of place or out of context. I try to re-read everything, but sometimes things slip through.

Proof and Test

The same care needs to go into our project deliverables. Proof, proof, proof. Test, test, test. When you hand a deliverable over to the customer – unless it’s understood that this is an early draft – then you’re telling the customer that this is done and the best I can do. It better be correct. It better be accurate and read well. And it better be free of simple typos, for crying out loud.

Bad Example

I had a project with a major US airline where I had two business analysts working on the project. One was more experienced than the other and was really acting in a mentoring role to the other one. The less experienced one was the BA actually doing most of the work. The understanding was – for my team AND for the customer – that the less experienced BA’s work was being overseen and proofed by the expert BA.

Ok…so when we had to go through 5 iterations of the Business Requirements Document (BRD) going to the customer with typos, inaccurate table of contents items, misspellings, missing graphics, etc. you can imagine how quickly the customer satisfaction we were building started to disappear! The customer couldn’t understand – and rightly so – how a team of 5 skilled technical resources (including me as the Project Manager) couldn’t turn in an accurate BRD without typos. Customer confidence dropped like a rock.

Never Assume

I was in the wrong for assuming that between two experienced Business Analysts that they could get a document handed over to the customer that was free of typos. I was busy, everyone was busy, and I expected it to just get done and be done right. It wasn’t until we started incorporating peer reviews for EVERY SINGLE DELIVERABLE that went to the customer that we started handing over error-free documents. We conducted peer reviews on the BRD (finally), the Functional Design Document, the Test Plan, and every piece of information that went to the customer in written (or electronic) form from that point on and we got it right. I even had the full team review the status reports, weekly status meeting notes, revised project schedule, and issues/risks lists before sending them off to the customer in order to ensure that the customer did not see any more incorrect and unprofessional submissions from our team.

Summary

Never take for granted that everyone cares as much as you do about the output that they deliver. Yes, it has their name on it, but if it’s your project it also has your name on it and everything comes back to you as the Project Manager. Work hard to ensure that emails are accurate and have the proper attachments the first time, that status reports are accurate, that status notes are accurate, that your project schedule has been updated with everything that the customer is expecting to see, and definitely make sure that the documents you deliver as part of your engagement are free of the simple errors and typos that make a professional team look very unprofessional.

This won’t necessarily increase customer satisfaction because it’s really just an overall expectation they should have anyway, but at least it won’t decrease customer satisfaction and that is definitely a good thing.

Related posts:

1. A Quick Guide Project Management Methodology
2. Project Success Series: Ensuring Customer Satisfaction
3. Project Management: Is PMP Certification Worth It?

Related posts brought to you by Yet Another Related Posts Plugin.

I’m assuming that most of you are like I am…you’ve been part of organizations that had good PMO’s, bad PMO’s and no PMO’s.  What set the good ones apart from others or at least seemed to make a difference?  Or if yours was bad – what made it so?  Why, in your mind, was your organization not served well by the presence of or creation of a Project Management Office?  And if you do not have a PMO, do you think your organization would be well served by one?  Why….what is lacking that you think a PMO would fill?

That’s a handful of questions and I’d like to hear feedback from anyone willing to offer information and answers – either anonymously or not.

Let’s assuming you’re in the category of individuals who think your organization is not being served well by your existing Project Management Office.  I’d like to hear your thoughts and reasons, but first I’m going to take a stab and what I believe are five reasons that the PMO sometimes does not meet the org’s needs.

• Executive Management is not Included in the PMO Process
• Training Plans are Non-Existent
• Common Templates and Processes do not Exist
• Poor Upward Project Reporting
• Major Projects Circumvent the Process

Let’s look at each of these in a little more depth…

Executive Management not Included in the PMO Process

This one means exactly what it says.  If your Project Management Office acts independently and either doesn’t report detailed project status up to executive management or if executive management doesn’t care what your PMO is doing, then your PMO isn’t relevant to your organization and it isn’t serving it effectively.  That may be the PMO’s fault and it may not be.  It’s sad if you have a PMO that your CEO does not find important enough to follow, view project status or have any interaction with.  Either your PMO Director is not promoting your PMO well, proper and meaningful reporting is not in place to make it relevant, or your CEO is clueless. 

Training Plans are Non-Existent

Most project managers could use additional or refresher training.  Technology changes, better processes evolve, and – in the case of IT shops – application development processes can change.  To stay current, to stay cutting edge – there needs to be training plans in place for the members of the PMO.  Otherwise, even if your PMO is important to your organization now, it may become irrelevant in the future as more and more PMO members become disgruntled with lack of growth opportunities and move on to other positions and companies.

Common Templates and Processes do not Exist

If your PMO is flying by the seat of it’s pants, then it’s not functional and it’s not likely to last.  It must have repeatedly process to be relevant and for the company to have confidence in it’s effectiveness.  Otherwise, no one will no for sure why one project was successful and another was not.  With no consistency your organization will not know what to tweak or fix in order to make things right or better next time.  Lessons learned will mean nothing if there is no consistent process and no consistent, meaningful templates in place.

Poor Upward Project Reporting

This one takes us back to the first point…the involvement of executive management.  Exec management may not care or get involved and that’s bad…but if there’s no meaningful mechanism by which to report project portfolio status (dashboards, etc.) to executive management, then it’s very difficult to show or prove PMO relevance to them.  You can show them how the PMO is making a difference if you can’t show them what that difference is.

Major Projects Circumvent the Process

This one may be the biggest tell tale sign that your PMO is not serving the organization well.  If smaller and less meaningful projects are being run through the PMO and managed by project managers…then that’s great.  But if they major projects go elsewhere within the organization and are managed by individuals that are not part of the PMO, then it’s obvious that executive management lacks the confidence in the PMO that is necessary to make it an integral part of the company’s success. 

These are just five signs…if I think of more I’ll post them.  If you have some to share please either post them here or email me at brad@bradegeland.com or both.

Related posts:

1. Criteria for Successful Project Management Offices
2. How to Make Your PMO More Visible
3. June Survey: Project Management and the PMO

Related posts brought to you by Yet Another Related Posts Plugin.

You know how things are when you begin a new relationship?  Remember how it was when you and your wife or husband first met?  Everything is exciting and new.  Ok, that’s not exactly how a new project is, but you get the picture.  When we start a new project, everything is fresh and new.  No budget issues, no project timeline issues, no issues whatsoever!  No one has complained…as far as you know requirements are in place and ready for work to start.

Is it Possible?

How do we keep that new car smell going longer?  It always seems to dissipate so quickly.  Everyone starts gung ho on the project.  No issues or roadblocks, no customer complaints, and the relationship with the customer is never strained at this point.  How can we keep everything cohesive and everyone fresh and focused intensely on project success?

The reality is we really can’t.  We’re all getting our project resources from a matrix organization and therefore everyone has not only your project priorities, but priorities of their own from other projects and from their management.  Customer issues will arise because requirements are never perfect and nearly every project has change orders (all should, but not all are caught or enforced….lots of ‘free’ work gets done or promised to the customer).

Keep Everyone Focused

As the Project Manager, it is our goal – and actually one of our key responsibilities – to keep the project team members focused on the prize.  That prize, of course, is the end goal of a successful on time and on budget solution for the customer.  How do we do that?  To really be successful, we need to keep our focus on the following:

• Aligning our tasks with the goals and mission of the project
• Assigning resources with relevant and meaningful tasks
• Keeping resources interested and challenged (this is often a tough one)
• Keeping everyone well informed with status information (weekly status reports, status meetings, adhoc communications, etc.)
• Keep track of the budget
• Keep the project schedule revised, accurate and in front of everyone

The well-informed team will retain more focus on your project and the tasks you’ve assigned to them.  Allow them no room for excuses – avoid the grey areas of who is responsible for what.  Keep the customer on their toes and aware of what is expected of them.  And keep them well informed of status so that they have no surprises.  Fewer customer surprises mean fewer customer complaints and less chance of having a dissatisfied customer.

Summary

You can’t keep it fresh throughout the project.  But knowing what causes things to stray like lack of focus, out of date information, unassigned tasks and lack of ownership and accountability will help you to steer clear of those issues by spending your efforts on performing the right PM tasks.  Strong and confident leadership will help you get to the end goal.

Related posts:

1. Reputation is a Fragile Thing
2. Agile Project Management
3. Common Project Issues: R & D – Too Much “D” and Not Enough “R” – Part 1

Related posts brought to you by Yet Another Related Posts Plugin.

Not everyone is cut out to be a Project Manager.  Being a PM is not an exclusive club.  It’s not even necessarily a highly desirable profession.  You get a lot of visibility, but not necessarily a lot of recognition.  That often goes more to the technical team than the PM, unless the project is very successful and highly visible.

I’ve written an article on the Background of an IT Project Manager and I’ve written five articles so far on the Characteristics of a Project Manager.  Here I’d like to look at five possible signs that indicate you may not be choosing the right career as a Project Manager.

Like Technology more than People

If you’re not a people person and prefer technology over people, then it’s not likely that you’re ready for a career as a Project Manager.  PMs are often thrust into customer-facing roles and are looked upon to lead a team of skilled resources on projects.  They must be ready to present materials, lead status meetings and status calls, initiate adhoc communication, and just in general be very confident dealing with people. 

If that’s not you, then run don’t walk.  If you prefer technology more than people you may be more designed for the role of the techie on the project – the person who develops the solution, not the individual who maps out how and when it will be delivered.  And patience with your team and the customer is critical.  If you don’t have patience, don’t sign up to be a PM.

All People, No Technology

Likewise, if you’re all about people but do not have any technical background then running IT projects as a PM is not for you.  I still contend that a good IT PM must have some technical background in order to be trusted, understood, and followed by the technical resources they are leading on a long project. 

You might get away with it on a very short engagement just by being a strong, confident leader.  But on a 6-12 month engagement or longer you’ll be exposed and the technical team will question decisions, etc.  I’ve seen it happen and I’ve witnessed very frustrated PMs who aren’t PMs anymore.

Don’t Handle Pressure Well

Being a PM means you have the target on your forehead for the entire project.  The Project Manager has to stay on top of status, project schedules, issues, risks and all project communications constantly.  Pressure is frequent throughout the project. 

If you don’t handle pressure well, then being a PM is probably not the best choice for you.  Being anything in IT is probably not for you, for that matter….because pressure on IT projects is felt pretty much throughout the entire team and throughout the entire project duration.

Need for Constant Recognition and Praise

Like I said earlier, you can get a lot of recognition, but it’s harder to get good recognition than it is to get bad recognition.  On the surface, much of the good recognition for a successful project will often go to the technical resources that developed the solution.  This, of course, depends on the company, but it is common…and it’s ok.  The developers likely did great work on a successful solution.  You led, but you didn’t create…and that’s ok. 

If you are one who needs constant praise, then a Project Management path is probably not for you.  It’s rewarding, but most of your rewards will likely come from the relationships you build on your teams with your team members and with your customer, not from the overflowing of praise and recognition you hope to get on a project.

Shaky Problem-Solver

Being a PM means you’re required to be a confident decision-maker.  Look to your team and other available resources – including your customer – as sources to help you solve issues and make decisions.  But if you’re inclined to run from problems or put them off and hope that they resolve themselves or that someone else steps up to solve them, then a PM career is not for you.

At every critical problem point, both your team and your customer’s team are going to look to you as the key leader and decision-maker and you can’t back down.  If you’re shaky in your decision-making or tend to be wishy-washy when it comes to problem solving and leadership, seek a different path for your own good.

Summary

These are just five – I’m sure I could come up with more and I probably will.  I would definitely welcome your input, as I’m sure the list could be nearly endless.  Please share your thoughts on what you’ve seen ‘not work’ in the PM field.  I’m sure everyone has some great colleague stories.  Thanks.

Related posts:

1. Five More Signs You’re Not Cut Out to be a Project Manager
2. When Your Management Lets You Down
3. What if…There was No Project Management?

Related posts brought to you by Yet Another Related Posts Plugin.

Internal vs. External Projects

External projects that are being run for larger customers are usually well-planned, well-thought out, and well-funded. That’s certainly not an all-inclusive statement and things do happen, but the large, external projects usually have some significant planning into them prior to starting the project – even if their lack of well-documented requirements makes you think otherwise.

From my experiences, internal projects are never as stable as projects run for external customers. The can start and stop on a dime. They can be started prematurely only to find out there really isn’t any funding available. Personnel changes can kill a project immediately. And overall organizational changes can significantly impact a project’s goals, mission, and priority in the organization.

Let’s look closer at what happens when management changes the scope of your project and ways to best strategize and aggressively act.

The Project Begins

So, you’re project was assigned, you’ve met with the internal business project sponsor and documented the project request along with high-level requirements. You’ve scoped the project in terms of timeframe, required technology, resource needs, and budget. You’ve presented this to management, received the ‘ok’ to move forward and you’ve presented a high-level proposal of budget and timeframe to the project sponsor and he’s accepted it.

Time for the Change

Now it’s ‘go’ time. The project starts…and then it happens. Something happens…an overall direction change or an internal business unit change or whatever, but now you’re being informed that your project is changing direction. What started out – as happened to me – as a simple intranet website attached to a database that allowed internal personnel to check on the status of airplane parts in for repair is now going to be – in midstream – an internet site that allows your organization’s customers to check on their own status’ and submit requests and interact with support personnel in your organization.

It’s all possible. What makes it difficult from a project management-standpoint is the following:

• Budget is already set
• Project personnel are already onboard
• Timeline and expectations are already set
• Work has been performed that may have to be re-worked

Challenges for the Project Manager

Planning and aggressive action will need to be taken in order to ensure the best chance for success in terms of final outcome, least impact to budget and timeline, and resource addition and retention.

It can be frustrating for resources to be part of a project that seems to lack direction or seems to be floundering. The PM must work with his team to re-define the new project scope in terms of requirements, resource skill set, budget and timeline. One risk at this point is losing key resources back to their departments (assuming shared or borrowed resources) as a new, longer project timeline may mean that the current resources won’t have the availability to complete the project and must be replaced. As the PM, it is critical to identify this potential and mitigate that issue/risk quickly to ensure that you do have the proper resources for the newly scoped remaining portion of the project.

Since this is obviously a major scope change, the new budget and timeframe will need to be presented to the business project sponsor to obtain sign off and ensure that there is the necessary funding available to proceed.

Summary

A major internal project scope change can take the project manager from working on an ordinary project for an internal business unit to working on a highly visible project that has now become a very important part of your organization’s business goals and brings quick recognition to you. This can be good or bad depending on the outcome – your fast response and aggressive planning at the point of scope change will likely mean the difference between success and failure.

Related posts:

1. The Art of Negotiation – Part 1
2. Dealing with Unreasonable Customer Expectations
3. Agile Project Management

Related posts brought to you by Yet Another Related Posts Plugin.

I’ve discussed the effective listening issue previously. In order to avoid miscommunication, misunderstanding, and heading down the wrong path with something, it is imperative that we listen carefully to our team members and to our customer. We know this…and we all try hard to practice this.

So let’s examine things that our customer says or does and try to figure out what they’re really trying to tell us.

What the Customer Says…

Have you ever been told by your customer that “that’s not what Sales told us”? Or have you been told by your customer that they needed Phase 3 implemented in place of Phase 2 and Phase 2 pushed out to the Phase 3 timeframe? Have they ever said, we’re still gathering our internal requirements from our SMEs and we’ll fine-tune things as we go along?

What They Really Mean…

I have heard each of these things and other similar requests and pieces of information from my customers at one time or another. They are telling you something. Deep down, the customer is telling you indirectly that they’re ill-prepared to start this engagement and therefore risk and issue assessment better be a top priority because you’re going to have a few of them to deal with.

A customer who didn’t iron things out well with Sales isn’t truly ready to start. If possible, you – as the PM – need to step back, have another Sales-to-Professional Services handoff meeting and postpone the start of the project long enough to figure out what you’re walking into.

A customer who hasn’t mapped out their needs, requirements, and business processes well enough for a multi million dollar enterprise-wide implementation to know what phase needs to be implemented when is clearly not fully prepared. Yes, things can change on their end of the business that can switch their priorities around slightly, but for some of these large implementations we’re all dealing with clients who have spent considerable time preparing and acquiring funding. Major changes like switching phases around – which can have major project, budget, and personnel implications – should not be taking place at that late date.

And certainly a customer who is still fine-tuning their requirements while meeting with you to document functional requirements clearly wasn’t ready to get started. Again, this is an example where it is best to halt the project, send the customer back to perform further work on requirements, and then proceed.

Point of View

Now clearly I’m writing this from the Project Manager’s standpoint and what’s best for the delivery team and what’s best for the overall success of the project. I’m not writing this from a customer satisfaction standpoint, or from the standpoint of your organization’s bottom line or the executive management viewpoint. I’m fully aware that most of the time your management is not going to support the notion of pulling the plug on the project to give the customer more time to prepare – especially if that is not a request coming from your customer.

How We Have to Respond…

So, how do we make this work? Well, since we’re all Supermen and Superwomen in Professional Services organizations, we just DO make it work. But seriously, we put our heads down and push forward with the customer to fully define what it is they need. Additional requirements definition, switching phases around, more training, etc. etc. Whatever they need, we try to accommodate.

We still need to pay attention to the timeline and budget and identify where change orders are needed and present those to the customer. But when we’re flexing for the customer, those things that require more time or money are easier to push through with the customer anyway.

Related posts:

1. When the Customer Doesn’t Know What They Want
2. The Art of Negotiation – Part 1
3. The Responsibility of Defining Requirements

Related posts brought to you by Yet Another Related Posts Plugin.

Sales says “yes” to everything, right? Come on, that’s the stereotype that we all have, isn’t it? Sales promises the moon, hands it off to us and now we have to deliver. Or worse, Sales promises some vague idea of the moon and now the customer is expecting the full moon and we have to work very hard (and dance) to reset those customer expectations.

Why Not?

So, we think we have to go into the engagement saying ‘no’ and resetting expectations. And we think that we need to monitor scope – which we do – and say ‘no’ constantly to customer changes and requests – which we don’t. Here’s why….

• Saying yes leads to change and change leads to more work and more revenue
• Saying no is usually unacceptable to most clients (the customer is always right, remember?)
• Saying yes or at least entertaining a ‘yes’ makes the customer think you’re easier to work with

What is the customer usually asking for? Training that they thought should be included as part of the engagement? Additional data integrations beyond what the SOW called for? New or additional functionality that wasn’t mapped out during Exploration? There are a million different things that the customer can be asking for and all can mean additional revenue if negotiated properly. And saying ‘yes’ rather than ‘no’ will likely mean a happy, referenceable, and return customer.

Approach is Everything

How you handle the customer requests or the needs that have caused this decision point is very important. Take a deep breath, avoid the urge to say ‘no’ and utter something like…

“This is an important request, but I believe that it might fall outside the scope of the original SOW and the original requirements of this engagement. If so, it can mean an impact to the project timeline and budget and may necessitate a change order. We will review the SOW and requirements and propose a solution by ‘x’.

You haven’t said ‘yes’, though you likely will. And the customer now has the expectation that the request is doable, but may cost money…the foot is in the door.

Increasing the Bottom Line

Another thing to keep in mind is that the later in the process that a change or addition (both are ‘changes’ in terms of the SOW and requirements) is made, the more revenue it will likely mean. A change order for an additional data integration made during Exploration may mean 5 hours of additional Design work, 10 hours of additional Development work, and 3 hours of additional Testing work. This is 18 hours of additional work and if your organization is billing at, say, $150/hour then that’s $2,700.

This same request made during Testing would take a greater effort since the system is already developed at this point and only Testing and Deployment remain. This same request may now mean 5 hours of Exploration effort, 10 hours in Design, 15 hours of Development, and 10 hours of specific Testing effort to ensure everything is integrated properly. That’s 40 hours or $6,000. This is just one example and a very small one – but it shows that a change requested later on can result double the revenue in some cases…maybe even more.

Summary

Saying ‘yes’ to change requested by the customer makes good sense. You’ll come across as willing and able and you’ll likely have a happier customer because you’re meeting their needs. But you’ll also be increasing your revenue for the project. I said yes, yes, yes to one large industrial supply organization located in the Midwest last year and it resulted in over $100k in additional revenue over a 4-month period prior to the Deployment of Phase 1 of their software solution. I was happy, executive management was happy, but most of all the customer was happy and very willing to pay for it.

Related posts:

1. The Art of Negotiation – Part 1
2. Common Project Issues: Underestimating Complexity
3. When the Customer Doesn’t Know What They Want

Related posts brought to you by Yet Another Related Posts Plugin.

As I write these articles and read your comments, it seems to come up a lot…”this is probably just common sense, but….”  So I thought it might be worthwhile to dive into this thought a little more here and get additional feedback from all of the readers.  So…before I write more I’ll state that I’d really like to hear your thoughts on this so please take some time to share them….they are always greatly appreciated!

Life Tasks

Is good, sound project management really just common sense?  On one hand, most of the things we do, or should do, in our life – if they are done right – are more about common sense than some sort of learned practice.  It makes sense to be organized, write things down, manage our money well so we don’t pay bank fees, manage our bills well so we don’t pay unnecessary late fees, eat right so that we remain healthy and go to the doctor and dentist regularly so that issues can be detected early and taken care of.  It makes sense to always wear a seat belt and to not drive a car after drinking alcohol and to not take illegal drugs, but people still do all of these things and with sometimes deadly consequences.

All of this, one might say, is common sense.  However, many of these things – and other, similar important things get neglected in our lives due to time constraints and budget issues or just plain stupidity.

What About PM?

So, what about project management practices?  Let’s look at the ordinary daily activities and responsibilities of your average Project Manager…

• Adhoc communication and follow-up with team members
• Updates with the customer on any necessary activities
• Budget and resource forecasting
• Preparation and delivery of status reports and issues/risks lists
• Revision and delivery of the project schedule
• Status meetings with the team and customer

Let’s naturally assume that the Project Manager wants to be organized and present themselves well to their team and the customer.  Given that assumption, then when we look at the above list, there really isn’t anything on there that would be contrary to that organized outcome, is there?  No.  Then it appears that performing all of these tasks to at least some degree would be common sense and just plain good practice.  Without training and mentoring they may not all be done well at first or in the right order or always delivered to the appropriate person, but they all make sense to be done and over time a good, willing and organized person aspiring to be a Project Manager would likely develop the understanding, knowledge and process to perform most of these tasks well and in an orderly fashion.

Don’t get me wrong…I’m not saying anyone can be a Project Manager.  I’m certainly not saying that Project Managers don’t need training and mentoring.  I’m not saying that PMP certification is not necessary – it has its place.  And all of these things will get a Project Manager off the ground much faster and can actually help a Project Manager be organized and successful on their very first assignment.  Left to chance, that’s not likely.

Summary

But that’s not really the discussion of this article.  What I’m trying to get down to in this article is that are the normal functions of good project management really just common sense?  I believe that they are.  Training helps…you’ll be successful much faster.  But if you’re an organized person and have the desire to be a good PM, then I believe that common sense will eventually get you down the path of performing the necessary tasks to be a successful Project Manager.  You may fail on a few projects getting there, but if you have it in you, you will eventually get there.

Related posts:

1. Do We Need Structure?
2. Common Project Issues: R & D – Too Much “D” and Not Enough “R” – Part 1
3. Reputation is a Fragile Thing

Related posts brought to you by Yet Another Related Posts Plugin.