Project Management Tips || Project Management, Collaboration and Knowledge Management Blog » sales

Upfront Project Management Involvement

Brad Egeland — Fri, 09 Jul 2010 17:28:38 +0000

I recently had the pleasant opportunity of having a discussion with several members of an organization who seem to be ‘getting it.’ And by getting it, they seem to understand that Sales has their definite purpose, but before everything is locked in place on an engagement, that Sales team really needs involvement from the delivery team to make sure this is all going to work. Sounds logical, right? Well, many organizations are making it a lot harder than it should be. I apologize if this sounds old to you since I’ve written about it before…but I hope you’ll stick with me and read on…

Sales is great, but….

Sales is obviously a key organization in any professional services company. Without sales, we’d have no projects to work on. However, many companies that I’ve worked with or for seem to think that there is a distinct line between Sales and the delivery part of the organization. You often hear, “Here, Sales closed this deal and now it’s your project – link up with Sales and get the handoff information so you can start the project.” Those words make me cringe. There are probably a long list of things that are wrong with that process, but I can give you three major ones right now:

#1 – Sales is primarily concerned with the sale

Sales is worried about making sales. After all, it is their job. And their salaries, commissions, and bonuses depend on it. If they didn’t make the sales, the rest of us in the professional services organization would have nothing to deliver on.

What’s wrong with this? Nothing really – but as I’ll discuss in #2 below, they aren’t Delivery and therefore are not in tune with what Delivery needs out of the Sales process.

#2 – Sales isn’t Delivery

While Sales is very important, they are not the same as Delivery and vice versa. Each have their own concerns, interests and needs to look out for. Sales can’t automatically assume what information Delivery needs and Delivery can not begin to assume that Sales will gather all relevant information needed by Delivery to actually start work on the project. And this topic leads us into the next…

#3 – Delivery needs specific information

To actually being the project with the customer and with team members, Delivery – specifically the project manager – needs specific information related to the engagement. This necessary information, of course, varies by industry, company, and even by engagement, but it is critical and the delivery organization needs this information before it can move forward with the customer.

I can’t tell you the number of times that I’ve sat in front of the customer or that I’ve been on the phone with the customer and I’ve been surprised that they weren’t told ‘x’ or didn’t have ‘y’ information for me. There were too many assumptions being made between Sales and Delivery and the end result was sometimes humiliation in front of the customer. And that only serves to decrease customer satisfaction and confidence in the delivery team’s ability to deliver.

Summary

For the average professional services organization to be successful, the delivery team needs more visibility into the sales process. I don’t think it’s critical that the project manager is involved throughout the sales process – that would be overkill. However, it is important for the PM and probably others in the delivery organization to work with Sales during the sales process. Key questions can be asked of the customer and answered by the customer that will serve to get the project off on the right foot, get the delivery team better information to kick off the project, and provide the delivery team with better customer requirements heading into the engagement.

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

The Project Resource Request

Brad Egeland — Sat, 14 Nov 2009 02:30:18 +0000

Here is yet another template that I am digging out of my archives to provide here. As you can easily guess, this document is designed for requesting resources at the beginning of your project based on information in your statement of work (SOW) and the estimates of resource requirements that either you or Sales put together in the pre-engagement process. It is also helpful for requesting additional resources during the project.

How useful this is to anyone depends on the organization they work in. If you have a mature PMO with processes in place, then I would guess that you already have a standard form or spreadsheet to use to request resource for your project. However, if you’re one of just a few PMs or personnel acting in a PM role in your organization or you’re in the process of building some PM processes for a newer organization or even setting up a new PMO, then any template may be better than nothing.

As with all of these documents, if you want the original Word doc file, just email me if you think this will be useful or helpful. And please, provide your own example if you wish. We’re looking to learn and share information so I’m happy to use and post whatever you would like to provide to the readers of PM Tips.

PROJECT RESOURCE REQUEST

[Save file name as: client name RESOURCE REQUEST yyyymmdd]

Client Name:	Title:
Project:	Date:
Project #:	Version:	Template 1.1 / Document 1.0

PROJECT DESCRIPTION

Provide a brief description of the project objectives and overall performance of the work to be performed.

WORK DESCRIPTION AND ROLE

Describe the work to be performed on the project by the resource(s) and what role the individual(s) will play on the project team.

DESIRED SKILLS

Describe the technical, business or professional skills needed by the resource(s) to successfully meet the needs of the project.

DELIVERABLES

Describe the deliverables the resource(s) will be responsible to complete as a result of their work on the project.

DATES REQUESTED

Starting: mm/dd/yyyy Ending: mm/dd/yyyy

HOURS OR % FTE

Provide the estimated number of hours or the percent of time the individual(s) will be need to be allocated to work on the project.

WORK LOCATION

Describe all of the locations the resource(s) will be expected to be located – if multiple locations, provide dates as they are know at the time of the request.

REPORTING STRUCTURE

Describe the reporting structure for the project and how the individual(s) will be expected to operate within this structure.

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

Construction Software State of the Industry from Software Advice

Brad Egeland — Fri, 13 Nov 2009 04:24:40 +0000

My friends at Software Advice have sent over another interesting original article that they have put together pertaining to software in the construction industry. This one comes from Houston Neal and it kicks off a series of reports the group is doing on trends within the construction software industry. Please visit their site at www.softwareadvice.com for the original report.

Construction Software State of the Industry Report

This is the first in a series of “state of the industry” reports in which we will share our observations on construction software industry trends. While reporting the recessive state of the industry is not breaking news, there are some interesting trends that we can share. Not everything is gloomy, and significant technological shifts are underway.

Our observations are based on roughly 6,000 conversations with construction software buyers over the past year. In these calls, our team listened to buyers’ “pain points” – the business problems they were looking to solve with new software. From there, we recommended what we felt were the best solutions. We later surveyed each buyer to find out if they ended up buying software, what they bought and how it all went.

Estimating and takeoff solutions are in demand

We’ve seen a very healthy level of interest in construction estimating software across all divisions. Over and over we hear contractors saying something to the effect of, “Bidding has gotten very competitive, which means I’ve got to be as accurate as possible.” As a result, we’ve seen a lot of estimators replacing their spreadsheets and manual processes with database-driven estimating systems.

We’ve also seen plenty of interest in on-screen takeoff software. We’ve seen three primary reasons for this:

Increasing the speed and accuracy of takeoff measurements (see previous paragraph);
Avoiding the printing costs of paper plans; and,
Responding to increasing electronic plan delivery and use of online plan rooms.

While demand for onscreen takeoff appears fairly strong and growing, we have seen a considerable amount of downward pricing pressure in that market.

Software as a Service is in the right place at the right time

Software as a Service (SaaS) is gaining momentum in many software markets. In fact, we would agree with other IT prognosticators that SaaS is a major structural shift in software deployment and is here to stay. We’ve seen this model succeed in the project management segment where there is a clear need for the collaborative benefits of web-based software. Moreover, the current recession is making the SaaS model more attractive to contractors because:

Subscription pricing can easily be added to a project’s general conditions;
Low up-front costs allow project managers to avoid an onerous approval process; and,
Faster and less expensive implementation makes the new systems more digestible.

We have not seen much demand for SaaS accounting, estimating or service management, although we do get asked about it now and then. We also have not seen many vendors emerge to deliver that sort of solution. We would not be surprised to see SaaS accounting and/or estimating solutions emerge over the next few years.

LEED credit tracking creates new demand

Another trend driving the adoption of SaaS project management systems is the increasing demand for LEED credit tracking. LEED certification has grown in popularity; so too has the need to track the detailed documentation requirements related to earning LEED credits. At their core, projects seeking LEED certification need document control and efficient communication. This is the core of what project management systems deliver. Going one step further, we are seeing a number of project management vendors building in specific LEED credit tracking modules within their system. Houston Neal wrote a great post on how to Track LEED v3 Credits in Project Management Software back in July.

Stimulus funds are trickling down, slowly

Government and other civil construction has remained healthier than commercial and residential construction. However, we have not seen the American Recovery and Reinvestment Act of 2009 (ARRA) have a big impact on software spending. We believe that the temporary nature of stimulus spending is not enduring enough to drive capital investment in software systems. Our hope is that ARRA will help accelerate the economy to a point where traditional IT investment levels resume. However, Chris Thorman recently wrote a quick analysis of the ARRA that showed that stimulus spending has had a nominal effect on putting roughly 1.6 million unemployed construction workers back on the job.

There has been speculation that Stimulus-funded construction projects would drive sales of project management software. The thinking behind the forecast was that ARRA projects would require a higher level of accountability. Project management software – known for strong document tracking capabilities – would provide the audit trail needed for this transparency. However, we have not seen this translate into a meaningful increase in sales.

Fewer accounting & job costing replacements

We’ve seen fewer firms replacing their core accounting and job costing systems over the last year. In prior years, we had seen replacement activity when company growth pushed existing systems to their limits. In the absence of growth, more firms seem to be staying put with their existing systems. Firms that are buying new accounting systems tend to identify one or more of the following three pain points:

Inability to achieve detailed job cost reporting from “generic” accounting systems;
Lack of integration to project management or service management systems; and,
The need to accomplish same amount of work with fewer employees.

Outlook for 2010

As the construction industry begins to rub its sleepy eyes, we agree with most experts who say that 2010 will be a transitional yet slow year for the industry as a whole. Company budgets likely won’t fully recover in 2010, limiting the purchase of construction software. However, so far we’ve noticed more activity this quarter than any other this year. Hopefully this level of interest will carry over to 2010.

This article originally published at: Construction Software State of the Industry Report.

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

Project Transition to Production Support

Brad Egeland — Thu, 12 Nov 2009 02:32:25 +0000

As part of methodologies I’ve previously discussed, the final phase is something that I call the Post-Deployment phase. Once the project is implemented – or deployed – the delivery team, the customer, and the project moves on into the Post-Deployment Phase.

The Post-Deployment Phase is the period of time when the delivery team remains as intact as possible to support the customer and the deployed solution before a final and formal transition to technical, or production support. This post-deployment period is usually somewhere between 30 and 90 days in length (30 is more likely) and that time period is set either during the sales process (and becomes part of the statement of work) or during the kickoff session.

Upon satisfaction of the post-deployment timeframe, support formally moves over to the company’s techical or production support team. The template I am unveiling here is a formal document to record that transition process, allowing the project delivery team to identify specific things about the project that the production support team will need to know. While reviewing this document, keep in mind that there are really three very key pieces of information in here that the support team will need to know the most about:

Schedule
Communication
Change Control Process

Communication is probably the most important piece here. It looks like a small portion, but in an actual document it will need to be blown out much bigger and contain all key contact information for every important point of contact in both the customer organization and the delivery organization.

PROJECT TRANSITION TO PRODUCTION SUPPORT

[Save file name as: client name PRODUCTION SUPPORT yyyymmdd]

Client Name:		Title:
Project:		Date:
Project #:		Version:

PROJECT DESCRIPTION

Provide a brief description of the project objectives and overall performance of the work performed.

SCOPE

Describe the deliverables/actions to be supported. Provide additional documentation as appropriate.

SCHEDULE

Describe the timing for support activities to be performed. Provide additional documentation as appropriate.

COMMUNICATION

Describe all required communication needs for support – What to communicate, to whom, in what format, and when. Provide additional documentation as appropriate.

QUALITY ASSURANCE

Describe the Q/A processes to be performed. Provide additional documentation as appropriate.

COST

Describe the support costs estimated by the project. Provide additional documentation as appropriate.

CHANGE CONTROL PROCESS

Describe how changes to the Production Support process will be addressed. Provide additional documentation as appropriate.

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

Closing Out the Project – Part 1

Brad Egeland — Fri, 02 Oct 2009 21:17:14 +0000

When you’ve reached the end and deployed the solution, then it’s time to make sure everything has been completed, all paperwork is done, and no stones are left unturned. It’s best to do that with some sort of checklist and I propose using a list similar to this:

Have all the project objectives been achieved?
Is the client satisfied with the overall project?
Have the necessary post-project support agreements been established?
What were the major concerns with the project?
What are the key lessons learned from the IT project?
What would you do differently?
Do you feel the solution was cost effective?
When would it be applicable to enhance or update the delivered solution?
What is your executive leaderships view of the project outcome?

In Part 1, we’ll discuss the first three items above:

Have all the project objectives been achieved?
Is the client satisfied with the overall project?
Have the necessary post-project support agreements been established?

Have all the project objectives been achieved?

This should be fairly easy to evaluate. Look at the project schedule and review all milestones and deliverables. Have they been met? At this point, we’re not considering timeliness or budget, we’re just concerned with did we hand the customer what we said we would. Did we supply a Functional Design Document, did we provide weekly status reports, was training completed successfully and signed off, was user acceptance testing (UAT) fully completed including re-review of all issues and did we get official signoff, etc.

Though it definitely shouldn’t be the first time during the engagement that you do this – it’s also a very good time to go back to your kickoff session notes and see that all points discussed during that meeting have been addressed. Make sure at this point that the customer knows you’re concerned that you fully covered everything for the project – they’ll appreciate it and it definitely helps with customer satisfaction levels and can increase the chances of repeat business from this customer.

Is the client satisfied with the overall project?

You may think you can simply answer this yes or no based on your knowledge of how things went on the project and the communications you had with the customer along the way – but that is not always the case. On some projects, you can end up being very surprised by the customer’s on viewpoint of their satisfaction levels.

I’ve had customers on projects that went extremely smoothly later state that they weren’t happy about how I handled something or weren’t pleased with one of my team members or how we delivered ‘x’ deliverable. And I’ve had other projects were I was certain the customer was just about ready to ask that I leave the project only to find out that they were very happy with me and with the team and how things were going. They were just demanding and somewhat needed. But we were meeting their needs and they were happy. It’s amazing how off your perception can sometimes be concerning your perception of the customer’s satisfaction level and what their satisfaction level truly is.

Have the necessary post-project support agreements been established?

Usually you’ll move from deployment into a post-deployment with some sort of pre-defined plan to both hand-off overall support to your tech support group but also you’ll agree to make your original delivery team available for a 30 or 60-day window to do immediate fixes should problems arise in the functionality of the delivered solution. That’s something that just needs to be worked out with the customer and something that was likely planned for both by Sales with the customer during the sales process and discussed between you and the customer during kickoff.

Just make sure that whatever the plan is, you act on it. If it’s to keep your team available for 60 days should problems arise, then make sure that every team member knows that and that each of their managers know that as well. It can have an affect on their next assignments, but it must be addressed in advance of deployment.

Next

In Part 2 we’ll further discuss these items in terms of the project closeout checklist/review…

What were the major concerns with the project?
What are the key lessons learned from the IT project?
What would you do differently?

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

Defining Risk Management – Part 5: Risk Tolerance

Brad Egeland — Mon, 14 Sep 2009 16:40:40 +0000

In this article, we will cover risk tolerance – your organization’s ability to tolerate different risks and identify those lines in the sand for tolerable risks and intolerable risks. Many factors can weigh in to an organization’s ability to tolerate certain risks. Some that come to mind are: how critical is the risk to the success of the project, will avoidance cost us on the project or cost us a certain level of customer satisfaction, and how does the cost/benefit analysis on the risk compare with the profitability of the project and the risks potential impact to that profitability.

This discussion on risk tolerance comes mainly from another excerpt of the book “The Project Management Question and Answer Book.” After reading, please feel free to share your thoughts on the subject as I feel this one is critical as we move forward on our projects. Do we care about certain risks? How much effort do we put into avoiding or mitigating certain risks based on their perceived financial or schedule impact…etc?

What is Risk Tolerance?

Risk tolerance is the willingness of some person or some organization to accept or avoid risk. In any group of people there are gamblers or risk takers and there are nongamblers or risk avoiders. People who have a low willingness to accept risks and the consequences of risks are called risk avoiders. Those people who are willing to take risks are called risk takers.

It is important to know that people and organizations have differing risk tolerances. Some customers do not want to risk the delivery of the project they are paying for by taking a chance on something new. Other customers will welcome the opportunity if the danger is not too great. For example, if we were manufacturing a product like some of the products that are advertised on late-night television, we would probably have a relatively high risk tolerance for the product’s failure. This is because the product is priced very low and is not going to put anyone’s life in danger. Customers buying very low priced items can expect them to have a shorter useful life than the advertising indicates. If customers want a product that will last longer, they buy an item that is built better and is probably more expensive.

This ability to choose is related to risk tolerance. In the mind of the consumer there is a tolerance for risk, which is expressed in his or her willingness to spend money. A consumer who is interested in having a highly reliable product that will last a long time is willing to pay more to get these features. Another consumer who is not willing to pay more to get a better product will be more accepting of the risk that the product will fail.

If we draw increasing impact and increasing probability on an X and Y axis, we can draw the locus of all points of equal severity as a line on the graph in Figure 1.

Figure 1: RISK TOLERANCE

Acceptable risks are any risks that are below and to the left of this locus of points of equal severity. Unacceptable risks are those risks that have a severity above and to the right of this severity line.

If we shift the severity line up and to the right, as in Figure 2, we are describing a person or an organization that is more of a risk taker. That is, the severity of the risks that one is willing to take is higher than before we shifted the line, and the person or organization shown is more of a gambler.

Figure 2: RISK TOLERANCE: GAMBLERS

If, on the other hand, we shift the line down and to the left, as in Figure 3, we are describing a person or organization that is less of a risk taker. That is to say that the severity of the risks that a person or organization is willing to take is less than before we shifted the line.

Figure 3: RISK TOLERANCE: AVOIDERS

In the classes we teach, we often perform the experiment of telling the students that we are willing to bet money on the roll of a single die, a cube with a number one through six on each side. (That’s half of a pair of dice to you nongamblers.) In the bet we say that if the die comes up with a one or a two, we win. If the die comes up with a three, four, five, or six they win. The question is, “Who would be willing to play for a penny?” Nearly everyone stays in the game at this point.

Then the stakes are raised to one dollar, and some of the people no longer want to play. As the stakes are raised higher and higher, more people drop out of the game. Eventually, unless there is a really hard-core gambler, everyone drops out of the game because the stakes are too high.

Even though the odds are very favorable, four chances out of six to win, when the bet is high enough, people will not play because the pain of losing is too great even when there are favorable odds. This is a great example of risk tolerance. Individuals and companies do the same thing with threats and opportunities. In risk tolerance we are concerned with people’s personal values and views as well as the company’s values and views. We may be dealing with a high-flying company that is willing to take many chances, but the individual who is representing the company may not be willing to stake his career on the risk you are suggesting. On the other hand, we do not want to be misled by the salesperson who is optimistic about everything until the sale is made.

Risk tolerance is somewhat describable in monetary terms. Our risk tolerance is how much we are willing to lose if the risk happens. In the case of a product that is sold to a consumer, the cost of the failure of the product might be the cost of the repair or replacement of the product if it fails. In the situation where someone’s life is in danger, these decisions become much more important. The tolerance for a risk that is life-threatening is very high indeed. This is because we cannot put a monetary value on human life.

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

Protecting Sensitive Data

Brad Egeland — Tue, 14 Jul 2009 04:01:48 +0000

I found this article from a recent issue of InformationWeek on sensitive data and the lack of security that we apply to it very interesting. I’ve personally managed many projects with sensitive data including employee health records, IRS data, student financial aid information, bank records, etc. I understand as a whole we do not generally do a great job of ensuring the integrity and safety of the data that our projects contain, transmit, integrate with, and process.

This article was written by Art Wittman, the director of InformationWeek Analytics, and it appears in the 7/6/2009 issue of InformationWeek. The title of the article is “Practical Analysis: Why Aren’t We Better at Protecting Data?”

We’re not as good as we should be at handling sensitive data. One strong data point toward that conclusion comes from the watchdog site Privacy Rights Clearinghouse (www.privacyrights.org), which has been doing its best to track both the cause and effect of data breaches since 2005. Since then, the site has cataloged more than 262 million compromised records. Some are more severe than others, and some have been handled better than others, but that grand total should serve to verify my basic thesis: As a group, we aren’t very good at this.

There’s no particular group of institutions that fare worse on this list than another– banks, state governments, federal agencies, educational institutions, insurers, healthcare organizations, and all other manner of businesses show up. What’s striking about the list is that a large number of breaches result from simple theft, and from either poorly devised or poorly implemented policies. For these sorts of breaches, tighter regulation typically isn’t the answer, and technology is only part of the answer.

Clearly, if systems with sensitive data are stolen from public places–one of the more common methods for exposures–there are policy issues, training issues, and technology issues at hand.

Do your policies allow for users taking significant numbers of sensitive records outside of the relative safety of your corporate walls? Maybe that’s not such a good idea. If it’s truly necessary, are your users adequately and regularly trained in how to keep that data safe, and have you employed the right technologies–like encryption–that will allow you to put some technical muscle behind your policy?

In our recent survey and report (available at dataprotection.informationweek.com) on data loss prevention, we found organizations still applying relatively the same policies to all users. At the same time, well over half have not yet implemented any form of encryption on mobile devices. Let’s face it, if you’re still more worried about whether Ed in accounting changes his password monthly to something longer than 12 characters with alpha, numeric, and punctuation symbols and is otherwise impossible for Ed to remember, while your sales team is running around with unencrypted client data on their laptops, something is very wrong with your data protection policies. To put it plainly, you’re doing what’s easy and cheap for you, but not what’s in the best interest of the business and its customers.

Other discontinuities between policy and risk aren’t hard to find. Poll respondents worried most about e-mail as a mechanism for losing sensitive data (47%), followed by removable media (32%); however, almost half don’t encrypt sensitive data on removable media. It’s a disaster waiting to happen, and the only thing worse than losing sensitive data is losing it and not knowing that it’s gone. Here, too, it’s a matter of policy, training, and technology. Log analysis software along with a policy and practice of actually using it is critical for protecting sensitive data.

Common sense and awareness of risks will go a long way in guiding DLP policies.

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

Project Success Series: Keeping Your Project Delivery On Time

Brad Egeland — Thu, 09 Jul 2009 22:30:30 +0000

As I referenced in Part 1 of this series (“Project Success Series: Ensuring Revenue and Profitability on Your Project”) there are four main questions that your CEO could ask you about a very visible or critical project you may be managing if you were to run into him in the hallway. And you better be ready to answer these questions and back them up with proof. The questions are:

Was the project on budget?
Was the project on time?
Was the customer satisfied?
Did the project deliver a usable solution?

Part 1 dealt with the question concerning whether or not your project was on budget. In Part 2, we’ll discuss the project timeliness issue. We need to take measures during the course of the project so that we can have a much better chance to say “yes” to the CEO should we run into him in the hallway – or get called into his office. If you haven’t had this happen to you yet, then maybe you haven’t managed a large enough or visible enough project yet. Don’t worry though, if you’re a successful project manager, you’ll get your chance eventually. Good times!

Extreme Attention to Detail

This is an easy one – at least it sounds easy. Put together a nice, tight project schedule that isn’t unrealistically easy to meet and not unrealistically hard to meet. Start with the Statement of Work, the draft information you received from Sales when the project was originally ‘sold’ to the customer (if that’s how your organization runs things), any assumptions made by Sales or the customer and include updates necessary from discussions that took place during the Kickoff sessions on the project. This is your opportunity to ‘fine tune’ the schedule and make it real, workable, and accurate.

Present the revised schedule to the customer and get their agreement or even signed approval, if necessary. Now this revised schedule will be what you manage go going forward. It will be the document that drives every weekly status meeting from here on out and what you check against when managing the resources, the tasks, the budget and when trying to incorporate any change requests by the customer or as necessitated by the ever-changing requirements for the project.

Above all else, keep it accurate and up-to-date. Critical milestones for the project are identified in the schedule and every milestone that slides or is missed is something that the customer will NEVER forget. Missed dates will work against you at every negotiating point in the project – especially when scope issues arise and you’re trying to convince the customer that they need to pay for these ‘out-of-scope’ issues.

Manage Scope Carefully

That brings us to scope. I covered this already in Part 1 so I won’t go too far here. Suffice it to say that you and your delivery team members must always be watching scope. Scope creep is the number 1 cause of projects falling out of budget and failing to deliver on time. If you don’t note something is out of scope, then it’s in scope to the customer but it’s still working against you because it’s not in YOUR schedule and it’s not in YOUR budget. You’ll end up eating it and looking bad to either the customer, your executive management, or both. Either way, you lose.

Keep Resources Engaged and Aware

As the PM in charge, it goes without saying (but I’ll say it anyway) that you must keep your skilled resources engaged and aware of where the project stands at any given time and what their current responsibilities are. If you assume they know just because they have a copy of your latest project schedule, then you’ll be finding yourself escorted out the door of your company by HR.

Make sure they’re attending the weekly status calls with the customer and that they are participating. Engage them in at least one weekly team call to check status. Make sure they’re copied on the latest resource forecast info so they know what’s expected of them now and two months from now.

Remember, these are busy, highly skilled resources who are already in demand on other projects. Yours is not likely their only assignment so keep your tasks in their head so they know what they should be working on. We all trip up and call our very own kids by the wrong names at times, how can we expect that these pros always have their 20 different tasks they are currently juggling straight and in-line with your expectations. The squeaky wheel gets the grease and the most communicative PM gets his or her delivery teams’ resources attention the most.

In the next installment in this series, we’ll discuss ways to ensure that the customer remains satisfied…thus helping to ensure your long-term tenure in your position.

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

Estimating the Project: Avoiding Potential Pitfalls

Brad Egeland — Fri, 05 Jun 2009 22:37:55 +0000

One old quote states “Any project can be estimated accurately (once it’s completed).” Yes…hindsight is always 20-20. The trick is getting it as close to right at the beginning as possible.

In the Beginning

Where I’ve come from recently, the PM involvement in the beginning of the project is scarce at best. That wasn’t the case earlier on with Rockwell Collins – the PM was everything…sales, requirements definition, implementation manager, deployment oversight, follow-on tech support. It was very interesting and challenging wearing every hat. But more recently projects have come to me fully estimated with a shell project plan already in place and also in the hands of the customer. That’s scary from a PM’s perspective.

Why is this scary? Well, the project has been priced without PM input. The PM – and preferably the Business Analyst, too – should review the requirements and SOW and provide input into the pricing of the project and certainly into the timeline and overall project plan before it is ever given to the customer.

What to Do Differently

I’ve said this repeatedly, but the PM must be involved in the estimating process. In order to have a solid estimate and ultimately a solid final price to the customer, the PM and BA need to review the requirements and SOW with the Sales or the Account Manager or whoever is serving at this point as the primary POC for the client. Together, these three entities should arrive at the price that is presented to the client.

These days, we should not have a “sales guy” doing all of the business development for an organization. We are doing the client a disservice by not putting someone incredibly knowledgeable about the product and the technology as the primary contact or at least including them upfront in the sales process.

Include Everything Reasonable

This is where Lessons Learned from other projects comes into play. For example, you may know that the data load for this project looks similar to one on a previous project that ended up taking 3 extra weeks. Well, the sales person doesn’t know that so it’s not priced into the project already if you weren’t part of the sales process. What do you do in a case like that? About the only thing you can do once the deal has been signed is bring it up during Kickoff as a potential risk and then track it till it becomes a reality. Revisit it often so it never becomes a surprise to the customer and even provide them with a ballpark dollar figure on what the added effort will be and have a change order ready to give them if and when it becomes apparent that it is necessary. And definitely pass this knowledge along to sales and management so future issues like this can be avoided when pricing engagements for the potential customer.

Summary

I realize this is a very specific example of an issue that probably should have been priced differently – and as you can probably guess this exact situation happened to me, which is why I was able to call it up so easily. However, this scenario could be applied to just about anything you’ve learned along the way on other projects and then see as a potential risk on a new assigned engagement. It’s just unfortunate that the individuals with this hands-on “in the trenches” knowledge of the potential pitfalls and risks that could and should affect pricing are not usually involved in the sales process at all.

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

Begin with the End in Mind

Brad Egeland — Fri, 29 May 2009 17:02:05 +0000

“Begin with the End in Mind.” This is a quote from Stephen Covey and it is Habit # 2 of The 7 Habits of Highly Effective People. I was recently reminded of this quote by a post on Twitter and it struck me…this is key thinking for Project Managers and, in fact, all business professionals who have responsibility for success in some facet of their existence. Begin with the end in mind.

“Begin with the End in Mind means to begin each day, task, or project with a clear vision of your desired direction and destination, and then continue by flexing your proactive muscles to make things happen.” This is straight from the 7 Habits book. In my opinion, this applies to both the project view and the daily view of what a project manager is up against.

Daily View

First, let’s look at the daily view. From a daily standpoint, the PM is interested in completing tasks, delivery status, communication and updates and getting to the end point of the day with both the delivery team and the customer team well informed and the proper progress made on the current tasks.

Now, does that mean that every single day the PM needs an update on every single active task? No, I don’t think so. That would be overkill. However, the critical tasks and the tasks that may be in danger of causing the project timeline or budget to slide – basically what’s hot right now and what’s at risk – need to be watched daily. At the end of the day, those are the tasks that the PM, the delivery team, and the customer team need to know are being taken care of and are still in alignment with the overall project goals and timeline.

Project View

From a project view standpoint, the end goals have already been set in the sales process, reviewed in the Kickoff session and well documented in the Statement of Work. And, of course, the end goals are laid out in detail in the project plan that is being revised and delivered every week and reviewed as part of a formal weekly status meeting with the customer.

Everything that happens on the project needs to be looked at with the project’s end goals in mind. That includes issues that come up, risks that are reviewed and hopefully mitigated, and definitely any potential scope issues that arise. All scope issues must be reviewed in detail and analyzed to ensure that additional work that must be performed is still in alignment with the project’s end goals and the customer’s “to-be” business processes. If project changes in the form of change orders are not in alignment with the end goals of the project, then the SOW must go back for detailed review to ensure that these potential changes are not moving the delivery team and the customer off track leaving everyone with an end solution that, once implemented, will not satisfy the customer’s needs and goals for the project.

Summary

It is critical to not be blind once the project is underway. It’s easy to get bogged down with the everyday tasks of managing a project and developing and implementing the customer solution. What’s sometimes hard is maintaining the high-level view of the project’s end goals and ensuring that the final solution is still aligns with the customer’s wants and needs.

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