Getting your message across

Project sponsors are busy people.  Project sponsors are senior managers in a business and that means they could well be managing several projects at once.  It’s not easy to juggle sponsoring multiple projects.  Added to this is the likelihood that they won’t ask questions when they don’t understand something.  Some senior managers are happy to admit that they don’t know or need clarification, but many would rather not confess that they don’t have a clue what you are talking about.

It’s up to project managers to make project sponsor’s lives as easy as possible.  There are lots of communications tips to use when dealing with senior people.  Here are some to try with your sponsor:

• Don’t use vague email subjects.  What do you think is more likely to be read: ‘Project ABC news’ or ‘Project ABC within 2% budget’?  If you label your emails in a way that makes it clear what the content is they are more likely to be read in a timely manner. Read more »

Data Security and the Cloud it Rode in on….

A couple of days ago my inbox filled me with intrigue when I saw the email from InformationWeek containing a link to one of their latest articles. The title: “7 Cloud Computing Myths Busted” by Serdar Yegulalp.

Since I’ve written a few articles on cloud computing and I’ve been interviewed for a couple others, I considered this “must” reading. Indeed, it is a very good article. Here, I particularly wanted to talk about Serdar’s myth #2 – Cloud computing is the end of privacy as we know it. This is something we all should be concerned with and – from the looks of data security concerns articles and discussions going around – we are…even if we are often not doing anything more than talking about it.

Cloud Computing and Data Privacy

So, is cloud computing really the end of privacy? Storing data and running apps in the cloud – meaning the apps are being run off of someone else’s server somewhere and your data is being stored somewhere that you likely will never see – doesn’t sound very secure on the surface, does it? Does that make you feel comfortable? No? It shouldn’t. But it isn’t the end of the world and the same prudence with data security that we take when handling data and apps within our own environment should be in place to secure your data outside our environment – it just requires some extra attention and policy adjustments on our part and possibly some extra verbiage in a contract that with the cloud provider of choice.

Mr. Yegulalp states: “What makes cloud computing such a fierce target for privacy advocates is not only the newness of the technology, since every freshly minted technology is a possible privacy suspect. It’s also the fact that cloud computing, on the face of it, can cause a huge degree of aggregation across multiple IT spheres. When you have many disparate things suddenly all under one roof, it translates into “single point of failure” and “all your eggs in one basket.” It’s not your data anymore, either; it’s someone else’s, and whatever happens will happen on his watch. There’s a chance that provisions about your data security aren’t even in the contract you signed.”

He is dead on with that insight. Afterall, most data leaks and theft happen within organizations as inside jobs, so the paranoia we’re all feeling is somewhat justified. And when you start storing your data on someone else’s system, you might not have the law on your side if expectations of privacy become a legal issue.

Our providers of cloud services must be proactive about their handling of data security, it must be built into the contracts you sign and you should be able to expect them to go above and beyond the call of data to make you feel comfortable about the safety of your data. And if you don’t have that comfort level, then move on to the next provider. But it’s up to you to see to it that the cloud services provider you are using is looking after your data. It’s not impossible to ensure this, it’s not impossible for them to maintain the safety of your data…it just takes prudent IT practices and forward-thinking policies.

One example – Mozy, the online backup service provider – addresses security/privacy concerns by allowing customers to provide their own high-grade encryption keys. The backed up data then cannot be read by anyone else – including Mozy. If you leave the service, the key goes with you rendering your left behind data useless to anyone else.

Summary

Cloud computing doesn’t mean the end of solid data security and privacy. It just means – as is the case with just about any new technology – that we will all need to be more aware of what we’re doing, adjust our practices and expectations accordingly and implement new policies that will help to secure our data in these cloud environments and help our cloud service providers to do the same.

The Lessons Learned Survey

Another useful tool in the Lessons Learned process is the Lessons Learned Survey.  This is a survey that can be sent to team members during or after a project, to solicit their feedback on how the project was conducted. It applies to any project; and questions can easily be added to focus on additional areas for your project.

A survey like this can be very useful for capturing lessons learned from the project while they’re fresh in people’s mind. The results can be summarized and recommendations passed on to future teams.

It’s usually best to send this survey by email to members of the project team. Let them know that results can be kept anonymous (to encourage people to be frank in their assessments). Send out this survey before any group “lessons learned” meetings. The feedback you receive from the survey can help point to particular areas that should get special exploration in the group lessons learned meeting.

Again, use this if it’s meaningful to your projects – it’s just another template or project tool that I’ve picked up along the way and wanted to share with our readers.  I’ve found it to be helpful in gathering post-project information from my team members on several key projects.

Post-Project Survey

SECTION 1: General Project Issues and Communication

The questions are geared to your particular project but wherever appropriate you can comment about release-level issues too.

Note: add any particular comments you wish….

1. How clearly defined were the objectives for this project?

___Very ____somewhat ___not very ___not at all

2. How clearly defined were the objectives for your work?

___Very ____somewhat ___not very ___not at all

3. How clear were you on your role in the project?

___Very ____somewhat ___not very ___not at all

4. How adequately involved did you feel in project decisions?

___Very ____somewhat ___not very ___not at all

If you did not feel involved, what decisions did you feel left out of?

5. How efficient and effective were project team meetings?

___Very ____somewhat ___not very ___not at all

What would you change?

6. How efficient and effective were technical meetings?

___Very ____somewhat ___not very ___not at all

What would you change?

___Very ____somewhat ___not very ___not at all

8. How adequate has cross-functional participation been?

___Very ____somewhat ___not very ___not at all

What were the problems encountered in the project-functional area relationship, why, and how could they be fixed? What cross-functional participation, if any, was lacking?

9. Do you feel appreciated, recognized and rewarded for your efforts?

___Very ____somewhat ___not very ___not at all

What if anything has been lacking?

10. To what degree is do you feel the entire team was committed to the project schedule?

___Very ____somewhat ___not very ___not at all

What if any issues are there?

11. To what degree have any “people issues” gotten in the way?

___Very ____somewhat ___not very ___not at all

What issues?

12. What communication, organization, structural problems in general were encountered, and how could we have done better in these areas?

SECTION 2: Schedule Estimation Issues

NOTE: This survey isn’t intended to collect exhaustive data on everything right now. We might decide after the post-mortem to work with a sub-group to investigate certain estimation issues, in order to help us improve next time around. This survey just helps us ferret out the rough scope of any issues.

Which of the following estimation issues did you personally have and what was the impact?

___ I was diverted to work on another project full-time.

Project: ________________________________________ Diverted for how long? ________________

Impact on your project work: ____________________________________________________________

___ I overestimated the amount of time I would have each week to work on this project.

The other work that interfered was ________________________________________________________

The amount of time per week it took up was ________________________________________________

Impact: calendar schedule slip of ____days ____weeks ____ months

___ My initial schedule did not include some pieces of technical design or coding work that I subsequently realized I had to do.

Describe briefly: ______________________________________________________________________

Impact (additional hours of work): ________________________________________________________

___ My initial schedule did not take into account certain project “other” work such as attending other people’s design reviews, doing two rounds of my own design reviews, etc.

Describe: ____________________________________________________________________________

Impact: calendar slip to my work of __ days __ weeks __ months

___ My estimates for particular tasks were not accurate.

Describe: type of task, how “off” the estimate was (days, weeks).

Why was it difficult to estimate?

What would help produce better estimates next time?

__ I unexpectedly had to re-do some work.

Describe: (Did something in the system design change that forced you to redesign? Was there a spec misunderstanding? etc.)___

Impact on your schedule: _______________________________________________________________

What could have helped prevent the problem?

Knowing what you know now, how would you do the scheduling/estimating process differently next time to avoid any problems noted above?

SECTION 3: Design, Implementation, Test Processes

1. How effective was our architecture/system design process in phase 2 and 3?

__Very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

2. How effective were our functional specs?

__very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

3. How effective were our design (or implementation) specs?

__Very __somewhat ___not very ___not at all

Comments:__________________________________________________________________________

4. How effective were our design reviews?

__Very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

5. How effective were our code reviews or hardware reviews?

__Very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

6. How well were interfaces defined?

__Very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

7. How well were design and interface decisions documented?

__Very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

8. How effective has interaction/cooperation between technical “Sub-teams” been?

___Very ____somewhat ___not very ___not at all

Comments:_________________________________________________________________________

9. How useful was your unit testing?

__very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

Did you take unit testing into account in your schedule? ______________________________________

10. How smooth do you feel Integration has been?

__very __somewhat ___not very ___not at all

Comments (why/why not?):___________________________________________________________

11. How comprehensive was integration testing, especially to allow SQA testing to get off to a good start?

__very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

12. How well is the build process working?

__very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

13. To what degree did you have the tools you needed for testing?

__very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

SECTION 4: Perceived Project Life Cycle, Development, or Process Issues

1. Is there any way in which you think our development process hampered this project?

If so, how?

2. What would you change about our development process?

3. What would you like to better understand or see better documented about how to use our process on this type of project?

SECTION 5: Closing

1. What were up to 5 main causes for schedule slips, and how could we avoid those causes in the future?

2. Was the project significantly delayed/hampered by outside dependencies (outside to the project, that is)? Which ones? How can we resolve these issues?

3. What were the main bottlenecks on the process?

4. What were the main sources of frustration in the project?

6. For the next project, how could we improve on the way project was conducted?

The Project Resource Request

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]

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.

Striving for Communications Effectiveness

I know I’ve said that Requirements Definition is the lifeblood of the project – and I still think that is true. But many aspects of project management are extremely critical to project success so if I can’t call communications the lifeblood of the project, then I’ll call it the backbone. Without effective communication – especially communication that originates or passes through the PM (since he/she is the critical communication focal-point) – then the project is likely to fail miserably.

Testing Communication Effectiveness

Whether the communication is written or verbal, formal or informal, the question must be asked as to whether or not it was effective. Did the information transfer that had to occur happen? Communications effectiveness can only be tested through feedback—the receiver is the ultimate determinant as to whether or not the message was received. The obvious test of communications effectiveness is to ask the receiver in the communications model to reiterate what has been said or what commitments have been made. Although they may be able to recite chapter and verse of what was originally stated, such regurgitation may not truly reflect understanding. Better instead to ask the receiver how they will act on the information or what the next steps in the process are, to ensure the communication has gone from interpretation to action.

Communication is Key

Communication is the cornerstone of effective project management, and yet most of it is done ad hoc, driven by individuals, personalities, and preferences, rather than by needs, protocols, processes, and procedures. Communication breakdowns are continuously cited as one of the key reasons that projects fail, which is why communication needs to be addressed as a critical activity and skill for project managers.

It is critical that managers improve or enhance their communications whenever possible. But “improving communications” is a vague concept. No two people are going to have the same notion as to what that means, unless com- munications goals are identified on the project. Communication is basically nothing more than an effort to make the world “smaller.” It is an attempt to create a common understanding and a common informational basis among various parties. It is the pursuit of commonality. It is an effort to bring individuals closer together.

How close is appropriate in the project environment? How deep must the common understanding be? The goal of communication in the project environment needs to be to establish a common understanding to the requisite level of depth. That level of depth will vary from project stakeholder to stakeholder. A security guard who affords access into the building may need only a single memo or e-mail from time to time, and needs virtually no understanding of the project plan or its intricacies. The customer needs to know what is being delivered and when, but may have no need to know how the work is being performed. Internal managers may need information on resource usage and performance, but may not concern themselves with project performance from day to day.

Summary

As a general practice, the goal of communication should be to clarify information to the level of depth required by the receiver by minimizing barriers that might inhibit understanding. In implementation, that implies a broad understanding of audience, interest, and environment.

The bottom line is the project manager must be the skilled communicator on the project and very adept and maintaining both formal (status reports, status calls, project schedules) and informal (phone calls, emails, adhoc meetings to discuss issues) with the delivery team, the entire delivery organization, and the customer.