The October PM survey is finally up at...

http://www.bradegeland.com/october-2010-survey.html


This month I'm look for answers on what the top frustrations are for project managers as well as what they feel are the top reasons for project failures.  All feedback is appreciated, but please only take the survey once.  I'll leave it active for a couple of weeks - check back for news here, on PM Tips, and on Twitter @begeland for updates and results.  Thanks!

As we’re delivering on a project for a customer, there may be numerous reasons why the project would be best moved to a phased project delivery situation.  The most common is the result of numerous requirements changes or change requests initiated by the customer while initial functionality is still badly needed by a specific date.  In a situation such as this, where the project cannot deliver the complete project or product by the deadline, there is still the possibility that it might deliver some useful part of it by the original promised date or close to it.

Technical projects composed of several subsystems, for example, often implement one subsystem at a time. Tenants can move into some floors in a new office building while there is active construction on other floors, and sections of a new freeway are opened as they are completed rather than waiting for the entire freeway to be complete.

Phased delivery has several benefits:

• Something useful is delivered as soon as possible – and in the case of many changes affecting the project, some critical base functionality may still be deliverable by the original agreed upon date.

• Often, as in the case of information systems, phased delivery is actually preferred because the changes introduced by the new system happen a little at a time. This longer time frame can reduce the negative impacts to ongoing business operations.

• Feedback on the delivered product is used to improve the products still in development.

• By delivering over a longer period, the size of the project team can be reduced; a smaller team can lead to lower communication and coordination costs. In addition, because the people are working for a longer time on the project, project-specific expertise grows. These factors should lead to increased productivity in subsequent project phases and to an overall lower cost for the project.

• Phased delivery allows for phased payment. By spreading the cost of the project over a longer time, a larger budget might be more feasible for the customer.

Modularized products, whose components can operate independently, can be delivered in phases. To determine how to phase a project or product delivery, you need to look for the core functionality—the part of the project that the other pieces rely on—and implement that first. The same criteria may be used in identifying the second and third most important components. When multiple components are equally good candidates, they can be prioritized according to business requirements.

Trade-off: Phased implementation increases functionality at the expense of schedule. If the approach requires old methods to run concurrently with new methods, it could also temporarily lead to higher operating costs.

Impact on risk: When components of a solution are delivered over time, the connections, or interfaces, become high risk. For technical solutions, that could mean corrupted data.

Information for this article was derived in part from Eric Verzuh’s book “The Portable MBA in Project Management.”

This article was originally authored for the PM Tips website - the original post appears here.

In a move that ends AT&T's exclusive tie-in with Apple, Verizon and Apple have jointly announced that iPads will be sold in Verizon stores beginning 10/28/10.  This further solidifies the rumor that Apple's iPhone will likely become available through Verizon in early 2011. 

Verizon will only be offering the Wi-Fi version of the iPad - wisely bundling it with their own mobile hotspot device and 1Gb data plan.  For more information, see the article that appears on CNN.com here.

You’re a small company with a new product that you know is going to turn the industry on it’s ear.  Everyone will want to use your product and you’ll be rich overnight…if you can just get the word out fast and effectively.  Well, you have it half right.  Get the word out effectively, but the fast part may not be necessary or even a good idea. 

Two negatives are associated with that:

 - You never want to grow your business too fast
-   Getting the word out too quickly could cause a major stir and rapid adaptation of your product before you’re ready and able to support that large of a customer base

So, how do you do it…how do you get the word out effectively and efficiently and grow your customer base for it in an appropriate fashion so that you’re not overloaded?  There are three key ways to do this….

1.    Offer an incentive to early adopters or beta testers.  If you’re confident about your product and it’s potential impact and if you already have a good customer base, then offer this new product to them for free for a period of time and allow them to help you work through some of the kinks.  You’re essentially getting extended testing for free – as long as the issues that come up aren’t so big that they kill the product and damage your customer following.  And if it’s your first product, you can do the same thing, but you won’t have your current customer base to draw on – you’ll have to find those customers/testers.  Mainly by shopping for them from competitors…it will be harder, but you’ll find them.

2.    Do the press releases and whatever news or magazine print you can garner.  Offer the info to any reasonable print publication you can.  Who you contact about this will depend heavily upon what industry you’re in….but if you’re in the tech industry the amount of publications and press release sites out there are more than enough to help you effectively get the word out.

3.    Offer guest articles to websites and blogs…post, post, post.  You can create a buzz for your product just by writing your own article in your own words and offering it as a free guest post to any relevant site that will have you…and there are literally hundreds of sites that will allow this.  Start doing this well in advance – perhaps even writing follow-up progress report articles on the product as your release approaches.  Create anticipation in your potential user community.  And, don’t forget to post about it on Twitter….often.

I originally authored this article for Real Deal Technologies here.

Sounds like an odd concept, doesn’t it? But seriously, does the project manager drive or just steer? Are they the ‘straw that stirs the drink’ (as Reggie Jackson of the NY Yankees and Darryl Strawberry of the NY Mets used to say about themselves)?  Or are they merely someone who lets others lead while they help steer the project toward a successful conclusion?

The Alternatives

In some organizations, overbearing PMO Directors want ultimate control over the portfolio of projects – even to the point of participating in all visible, critical projects on at least the status meeting level. I’m not of the opinion that PMO Directors should actually be leading many, if any, projects themselves – they should be concerned with the PMO, the overall portfolio of projects and the processes that make the PMO and the organization successful.But clearly the PMO Director who insists on participating in every visible project’s status meeting and kickoff sessions just needs more to do…they must have too much time on their hands or their responsibilities have not been clearly defined to them.

In other organizations, I’ve seen other managers have major control over a project. This most often happens on software projects where the software development manager – or possibly the tech lead – ends up with ultimate control of the project. This can happen for two reasons:

• Company policy or general practices dictate this
• Because the project manager lacks the authority, confidence or leadership ability to maintain control of his/her own project

The PM Must Take the Lead

Obviously, I’m of the opinion that the project manager is the straw that stirs the drink. The customer expects there to be one central leader on the delivery team side and customer confidence is usually much higher if that leader – that central point-of-contact – is the same individual who produces the status report, manages the budget, leads the status meeting, kicks off the project, handles the scope management and leads the delivery resources. That person needs to be the project manager. It’s what the customer expects and it’s what they should be allowed to expect.

Many of the projects I’ve been called in to fix or re-set customer expectations on or take over because customer confidence has been lost have been projects that were being led either by a business analyst acting in a dual role, a developer acting in a dual role or a project manager with little to no customer handling experience.

BAs and developers have enough on their plate without asking them to also be the organization’s main face to the customer and lead meetings and handle the normal daily project management communication and deliverables that every customer should expect. They have critical jobs to do and usually excel when they’re not interfered with and expected to lead the project.

Summary

The customer expects and strong leader on the delivery side and in order to maintain customer confidence and satisfaction, it is critical – especially on highly visible projects and projects with tight schedules and budgets. On these projects, the role of the project manager and the tasks that they perform are even more critical and should not be passed on to another manager or a talented resource on the team who is also expected to develop requirements and the ultimate solution. The project manager needs to be that straw that stirs the drink. They must be the one driving.

I originally authored this article for the PM Tips website - the original article can be viewed here.

In the wonderful world of scope management and scope creep…as a project manager all you have to go on is your organization of the project and your reporting tools. I’ve found that the three best ways to combat scope creep are:

Establishment and signoff (by the customer) of a Scope Statement or Document.

Establishment of a work-in-progress detailed project plan that the customer is reviewing with you on an on-going basis.

Management of the project driven by a detailed project plan and weekly status reviews of the project – that includes the customer – utilizing customized reporting from the detailed project plan.

For #3, my preference is to create custom filters in MS Project and utilize those filters to create 6 customized reports:

Tasks Completed Last Reporting Period
Tasks Started Last Reporting Period
Tasks Planned For Completion This Reporting Period
Tasks Planned To Start This Reporting Period
Tasks Past Due For Completion
Tasks Past Due To Start
Items #1 & 2 cover your areas of Progress on the weekly status report. Items #3 & 4 cover the Planned areas of the status report. And items #5 & 6 cover the Issues area of the status report.

I then include a section in the weekly status report that covers action items, who they are assigned to, and when they are expected to be completed. This area is meant to handle the on-going issues that come up during the project but that don’t really fall under the category of a Task to be included in the project plan.

When your customer needs work that falls outside of the agreed upon scope of the project, then we usually need to turn to two things – a Phased Implementation and/or Change Orders.

Phased Implementations

Many times requirements will either change or become more refined resulting in work that needs to be performed outside the original scope – either timeframe, budget or both. To keep the project on track in terms of implementing necessary functionality within the agreed upon timeframe, one way of keeping the customer happy is with a phased implementation approach.

Usually this will also have budgetary implications as well, since if it is effort beyond the original timeframe then it is likely effort beyond the original budget.

Working with the customer to agree upon implementing ‘x & y’ functionality by June 1st and moving ‘z’ functionality to September 1st is a way of keeping at least most of the project on track while redefining when the full functionality will be ready.
This likely results in one or more change orders, which we’ll address next.

Change Orders

Unless the PM or the PM organization is involved in the sales process (and I think they should be!), then the PM’s first chance to increase cash flow for the organization is to recognize additional customer needs and out of scope items. These are usually handled in the form of change orders. Some customer’s cringe at the mention of change orders and may even have you sign an agreement that there will be no change orders on the project. In those cases you just have to adhere to the original project scope and allow nothing to get in the way. However, when functional requirements are being fully fleshed out and turned into a technical design doc, many IT projects will realize the need for change order work. This can be a need for additional personnel with different skill sets added to the project, more reports, new screens, additional queries built into the software, more integrations than were originally planned…..you get the idea…the list goes on and on. In one case on one of my projects, the customer liked the Business Analyst so much that they wanted him onsite for the entire project rather than just for a couple of weeks at the beginning of each phase of the project. This customer had money and liked the team and wanted to ensure that everything went smoothly. They happily signed on for nearly $100k in change orders over a 3 month period including increased hours and living expenses to accommodate the BA onsite for the duration.

Conclusion

The PM definitely has help from his project team to keep the project on track as originally scoped. The BA and developer(s) will be watching for things that fall outside of the scope during design sessions. However, the PM has overall responsibility to track the scope, identify discrepancies and originate discussions and paperwork that will lead to changes such as a phased implementation and change order work. The earlier this is identified and the quicker it is discussed with the customer, the greater the likelihood of customer satisfaction. Document everything, create detailed change orders and get customer signoffs so that there are no questions at invoicing time.

I originally authored this article for the PM Tips website.  The original post can be viewed here.