Dangerous ideas – and how to address them (part 1)

Ernest Baker, PMP, gave a presentation at the recent PMI Global Congress North America called ‘Ten troublesome project management ideas and how to combat them!’ I thought the content was worth sharing, as he had some good, practical examples of why things go wrong on projects and what we can do to stop them from happening.

Baker is President of Start to Finish PM, Inc and the aim of his presentation was to make us, as project managers, more aware of the “potentially bothersome” ideas that some stakeholders come up with. By recognising them, we would then be in a far better position to combat the dangerous ideas and assumptions about project management before they become a significant problem for the project. Essentially, it’s all about managing stakeholder expectations.

So, what were his top ten dangerous ideas? We’ll look at two today, and the remainder over the coming days.

1. Just Do It!

Baker said that the top symptoms of a ‘just do it’ culture were:

• Executing without planning
• Meeting a scheduled by doing not by planning
• Creating a fixed date schedule by drawing up the plan before the scope is defined
• Evidence of people mind-reading and not getting proper requirements or estimates
• Ignoring the balance between scope, schedule, budget and quality (a variety of the triple constraint so beloved of project managers)
• Lots of activity but not necessarily a lot of productive work taking place

In short, working in a ‘just do it’ environment means that you’ll deliver your project by luck and working a lot of hours rather than skilled project management. And it probably won’t deliver to stakeholder expectations anyway.

If you feel that you work with stakeholders who hold this kind of attitude, this is what you can do to combat it:

• Agree how things will be produced as well as what will be produced: this offsets some of the issues around taking the time to plan
• Include project management tasks and outputs as deliverables in the plan
• Gather metrics about time spent ‘doing’ project management – again, this will show that it isn’t that time-consuming a task and makes it transparent.
• Don’t charge your project management time (if you do time recording) to product deliverables. Instead, charge it to those project management deliverables in your plan.
• Incorporate lessons learned and process improvements
• Send your stakeholders on some training!

2.  Rewarding Heroic Behaviour

Sometimes, you need to make a concerted effort to get something done. Being a hero is sometimes a good thing, but Baker argued that it is often heroes (and heroines) that get rewarded – whereas the project manager that doesn’t get their project into a mess goes unnoticed. There is a risk with rewarding hero-like behaviour – the project managers stepping in to sort out a mess may find themselves in a high profile, high success role, but being in a mess is not a behaviour to reward at all. Companies which value heroes often overlook those project managers who plug away at it, develop excellent project schedules and don’t mess up. Surely that behaviour is more worthy? Symptoms of an organisational culture that rewards heroic behaviour are:

• Projects being completed by the heroic efforts of a team
• The leader of that team being praised for their work and leadership
• Resources are allocated from well-managed projects and given to the ‘hero’
• There’s a focus on managing issues instead of managing risks

Moving away from this culture isn’t always easy. In fact, as a project manager there is a limit on what you can do to influence organisational culture at the highest level. But you can address this challenge in some ways:

• Reward your team for the behaviour that you want them to show i.e. structured, planned effort
• Establish your project objectives and make sure everyone is clear what is expected of them
• Define success criteria at the outset, including what this will look like for stakeholders, scope and schedule.

Tomorrow I’ll be looking at three more of Baker’s troublesome ideas and how to address them!

Project Management: How to Successfully Kickoff a Project

In my article titled “The Project Kickoff” I discussed how the project manager should handle a typical project kickoff session with an external customer on a sizeable engagement. In that post I covered what happened in the Kickoff phase – Phase 1 of the overall PM methodology I presented over eight articles and in summary form in “A Quick Guide to Project Management Methodology“.

One can say I use PMI, etc., but that doesn’t really tell the story. PMI provides the common terminology and practices, but what it doesn’t seem to do a great job of is laying out an entire PM methodology…one that you can follow, build a project plan from that means something in the real world, and manage the project and team from. The Quick Guide I laid out does allow that…and here I’d like to talk more about how the project manager successfully kicks off a project.

The Assumptions

For the purposes of this discussion, we’re going to assume that the project we’re talking about is visible, high dollar, important to your organization, and is for an external customer. Internal customers need a kickoff session, but it’s not usually too elaborate nor does it require as much preparation…funny how that works but the external customers often get top priority, the most attention and the best resources…especially if they’re paying decent money for the project. We’ll also assume this is for some sort of enterprise software solution that your organization offers.

Dropped in Your Lap

So a large project has been passed from Sales to the PMO and your PMO Director has dropped it on you. Now what do you do?

AT this point, Sales has completed their part of the process and you likely have a Statement of Work (SOW), rough resource estimates, specific contract dollar amounts, and a rough project schedule or at least milestone dates in front of you. Whatever you want to call it – kickoff meeting, planning meeting, strategy session – you must hold a face-to-face with the customer to go through these items and ensure that, now that Sales is out of the way, everyone is on the same page. Trust me, it’s not a given and depending on how your organization is run, it’s not even very likely. If you’ve read enough of my articles you’ll understand what I mean – remember when I found my business analyst crying in the hallway? If I’ve learned anything, it’s that you should never assume anything. There…that’s one of my BIG lessons learned.

Wrap Your Arms Around It

In order to prepare for the face-to-face, you first have to get your arms around what you’ve been given. Meet with Sales, go through the SOW with a fine-toothed comb, and review the pseudo schedule and budget that Sales likely passed on to you – and then make them both your own. And by that I mean re-create them how you want to manage against them. Beef up the project schedule with what you know must happen…Sales doesn’t have that PM detail in their heads of what happens on typical projects and neither did the customer when they were meeting with Sales. The onus for that is on you.

The Presentation

For the face-to-face, I always suggest a more formalized meeting to review the following in at least some detail:

• Statement of Work
• Draft project schedule (now with your revisions)
• Milestone dates (pull them from the schedule and review separately so that everyone is very aware of the key dates)
• Budget (if this is appropriate given the attendees and your customer’s preference)
• Your PM methodology (let your customer know how you plan to manage the project)
• Your change order process/change management practices
• How you intend to handle risks/issues
• Status calls and status reporting schedules
• Initial list of risks (if you’re prepared for this at this point…otherwise wait till you have your first status call)

Prepare a presentation deck and get it to the customer for review and agreement prior to the meeting. It will make for a much more successful and productive kickoff session as they’ll already have their questions ready for you – or even answered beforehand – thus, ensuring that uncertainty doesn’t extend into the Exploration phase which comes up next.

Who Should Attend

Face it, you’ll be outnumbered no matter what. I suggest this 1-2 day session should be held at the customer site and they’ll probably try to bring everything but the kitchen sink so be careful. Get a list of their proposed attendees and try to work with them to trim it down. I once had more then 30 customer attendees in a kickoff session and it nearly turned into a fiasco. We were able to trim it down for the 2^nd day, but I’d advise – as a lesson learned – to try to do that before going onsite.

At a minimum, here’s who should attend:

Delivery team:

• Project Manager (that’s probably you if you’re reading this)
• Business Analyst (ideal if one has been assigned…and if one isn’t assigned immediately after you acquire the project, scream! You’ll want their technical expertise available at the kickoff meeting)
• PMO Director (this attendee is not critical, but with a visible, high $$ project, they’re going to want to be there or will be forced to be there by the CEO)

Customer:

• Project sponsor
• Relevant SMEs that have or are defining more detailed requirements and business processes and know what the end users need (and may be the end users themselves)
• Customer Project Manager (often this person is more of a hindrance than a help, but if one is assigned, they need to be present)

Beyond that for the customer and you’re probably going to have too many. Remember, the SMEs are NOT one person…that’s probably 10-12 people depending on the size and type of your enterprise implementation.

Summary

Following these steps will usually ensure that you’ve brought the right people and information to the table to go through the details and get the project started off on the right foot. And it’s extremely important to do that as you’re likely to have some expectation resetting to do….Sales sets one expectation, but yours is the more important, and realistic expectation. Make sure you’re well prepared, well represented, and a little bit stubborn.

Equipping Your Mobile Project Staff – Part 2

This two part series on ways to equip your mobile project staff (PMs, BAs, developers, etc.) concludes with this article. In Part 1, we covered IP Telephony and Disk/Data Encryption.

In this Part 2, we’ll discuss Virtual Desktops, Remote Office in a Box, and Printing and Power. Again, this information is based on an InformationWeek article from late 2008 and re-worked here to apply more to the project workforce assuming a remote and geographically dispersed team that must travel to customer sites as needed to perform tasks related to design, development, testing, deployment, etc. of planned solutions.

The idea is to ensure maximum productivity to the workforce that is likely largely responsible for most of the organizations project revenue so while budgets must be watched and maintained, there are certain prices that just must be paid.

Virtual Desktops

Full disk data encryption will help IT breathe easier in the event of hacking and theft, but it offers little help to the traveling project manager who just lost his laptop in transit and has a project kickoff meeting tomorrow at the customer site. The wonders of desktop virtualization and advancements in flash memory are bringing new options to on-the-go employees who’ve experienced digital disasters.

When corporate applications are difficult to deploy via Terminal Services or application virtualization, complete virtual desktops environments can be the answer for off-site project workers who need quick access to custom computing environments from a public PC. Virtual desktop infrastructure (VDI) platforms are bleeding-edge technology in the eyes of many, but they’re evolving quickly and are based on proven server virtualization technology.

Remote Office in a Box

Vendors have finally heard the cries of many over the countless hours full of lost productivity and connectivity on the road. The remote office access systems available today are incredible compared to what was available just a few years ago.

Aruba Networks and Cisco are among the players in the remote access market that are making life on the road more bearable. With Aruba’s line of Mobility Controllers and Remote Access Points, the days of troubleshooting VPN client problems are gone. Simply supply your mobile workforce with small access points that plug into any wired Ethernet connection. The AP finds the mobility controller located at corporate headquarters and builds an IPsec tunnel that’s actually an extension of your enterprise wireless network. The Aruba AP is VoIP-friendly and quality-of-service-aware, so users can put down the expensive hotel phone and simply utilize a wireless IP phone.

Printing and Power

A good printing option for the mobile project workforce is the 5-pound HP OfficeJet H470wbt Mobile Printer. With its built-in Bluetooth and WLAN capability, coupled with its ability to print directly from a memory card, PDA, or digital camera, and powered by an optional cigarette-lighter AC adapter, you can now print 18 pages per minute in color, or 22 ppm in black and white, while stopped at a traffic light. Of course, if you try that too much you may be printing while stopped waiting for the officer to finish writing your ticket.

The HP printer lists for $350 – a small price to pay if you’re trying to rely on finding a nearby copy center that is still open late at night when trying to print on the road.

Don’t forget it also takes power to maintain productivity. Macs are offering up to 7 hours of battery life on new Macbook models. And HP appears to be leading the way overall with its EliteBook 6930p laptop, which has an optional expansion battery that can provide up to 24 hours of uninterrupted usage.

A Quick Guide Project Management Methodology

A few months ago I covered all 8 phases of my general project management methodology over 8 separate and fairly long articles. What I would like to do here is condense them into one – still lengthy – quick guide type article for general reference to anyone who might need it. Let’s get started…

Phase 1 – Project Kickoff

Purpose:

• Onsite meeting with the customer at the beginning of the engagement to review the SOW, the project team, the draft project schedule and milestone dates, and the process for managing the project

Activities:

• Prepare for onsite Kickoff session with customer
• Create/revise draft project schedule
• Create presentation slides for Kickoff session with customer

Deliverables:

• Kickoff session slide deck
• Initial project schedule

Phase 2 – Exploration

Purpose:

• Document business processes, further refine business requirements for the project, work with the customer to detail the difference between the “as-is” processes and the “to-be” processes. Further involvement by customer SMEs will be required.

Activities:

• Create the Business Requirements Document (BRD)
• Customer review and signoff of BRD

Deliverables:

• Business Requirements Document
• Revised project schedule
• Revised issues/risks list
• Weekly status reports
• Weekly status meetings

Phase 3 – Design

Purpose:

• Goal is successful completion and signoff of main Design phase deliverable, the Functional Design Document (FDD)

Activities:

• Work with customer SMEs and delivery team to further refine and finalize functional design requirements, reporting requirements, data migration requirements, data integration requirements, security requirements, etc.

Deliverables:

• Functional Design Document
• Revised project schedule
• Revised issues/risks lists
• Weekly project status reports
• Weekly project status meetings
• Assignment of development team members and other support personnel to the delivery team

Phase 4 – Development

Purpose:

• To develop a workable solution according to customer specs that is ready to move into the Testing phase

Activities:

• Develop a Technical Design Document (TDD) – mainly for use by the delivery team and the technical lead
• Develop the system to customer requirements
• Perform periodic demos or reviews to ensure that the solution is on track

Deliverables:

• Technical Design Document – optionally for the customer
• Periodic development reviews/demos
• Revised project schedule
• Revised issues/risks lists
• Weekly project status reports
• Weekly project status meetings

Phase 5 – Testing

Purpose:

• To ensure that the developed system is tested, matches customer requirements and is bug-free for training and deployment

Activities:

• Define testing approach
• Document Test or QA Plan
• Create test conditions/cases – this should be a customer activity
• Conduct system testing
• Conduct User Acceptance Testing (UAT)

Deliverables:

• Developed system
• QA or Test Plan
• User Acceptance Testing signoff
• Revised project schedule
• Revised issues/risks lists
• Weekly project status reports
• Weekly project status meetings

Phase 6 – Training

Purpose:

• To train the customer or the customer’s trainers on usage of the production-ready system prior to Deployment

Activities:

• Development and delivery of a training plan
• Development and delivery of training materials
• Setup of a training environment or server with a production-ready copy of the system
• Training-specific data loaded to the database
• Delivery of training, or train-the-trainers training

Deliverables:

• Training plan
• Training materials
• Training environment
• Training data in training database
• Revised project schedule
• Revised issues/risks lists
• Weekly project status reports
• Weekly project status meetings

Phase 7 – Deployment

Purpose:

• To implement the tested and production-ready system into the live customer environment and deploy to all relevant users

Activities:

• Setup production environment
• Load production data to the production environment
• Customer review and signoff of go-live readiness

Deliverables:

• Production environment
• Live data load to production environment
• Deployed production-ready system
• Revised project schedule
• Revised issues/risks lists
• Weekly project status reports
• Weekly project status meetings

Phase 8 – Post-Deployment

Purpose:

• To provide the customer with a window of time after go-live where the key delivery team members will still be available to the customer for issues, etc. and for knowledge to be passed on to the on-going support organization

Activities:

• Go-live support for an agreed upon timeframe (30-60 days) by the delivery team for the project
• Hand-off to support team
• Re-connect with the customer team for Lessons Learned sessions

Deliverables:

• 30-60 days of post go-live support by the current delivery team
• Lessons Learned documented and delivered to delivery team, customer team, and support team

With OS Project, Is Google Over-extending Itself?

As reported by Juan Carlos Perez, IDG News Service.

Google’s decision to build a PC operating system could be a master stroke or a colossal blunder, depending on whether the company has the resources that such an ambitious and long-term undertaking will require.

Google plays in a variety of extremely competitive markets, serving a broad scope of demanding customers and partners. Although developing an operating system could yield big rewards, it could also distract the company and make it more vulnerable to rivals.

Of chief concern is Google’s continued reliance on a single type of advertising for most of its revenue, despite efforts over the years to diversify its business.

Google still makes most of its money from search pay-per-click text ads, a market that it dominates but where loyalty from consumers and marketers is thin, making the company vulnerable to the development by a rival of a significant technology breakthrough.

In short, if someone built a better search mousetrap — as Yahoo, Microsoft, Ask.com and a host of smaller players are trying hard to do — Google would suffer a sudden drop in search usage and consequently advertising, crippling its finances.

Google’s attempts to build alternative revenue streams from display advertising remain nascent, despite the costly acquisitions of ad services provider DoubleClick and video-sharing leader YouTube, two properties Google considers key to this effort.

Bold initiatives to provide print ads to newspapers and spots to radio stations both failed. The company continues its attempts to build a TV advertising business.

Google executives are the first to admit that the company dominates the Internet search market because it toils long and hard every day to continually improve its engine technology.

Yet, not content with waging battle every day in search, Google also provides enterprise search and business collaboration software, competing against the likes of Microsoft, IBM, Cisco and Autonomy, and trying to win over business managers, IT managers and CIOs.

Read the entire story here.