WHO ARE THE CUSTOMERS ON TECHNOLOGY PROJECTS?

Webster's defines a customer as "one that purchases a commodity or service". In project work that involves technology change, end users of the to-be designed system are typically thought of as the customer. This group is most affected by the change on a day-to-day basis and has the steepest learning curve to go through. Communication plans are designed to first introduce this group to the coming change, followed by setting proper expectations around benefits and timing, and finally, ensuring end-user participation and skill development.

THE OVERLOOKED CUSTOMER

When a project begins, the world gets divided into those leading the change and those waiting for the change to happen to them. Focusing on the end-user is important, but overlooks those employees who participate in the design of the new system. There is an assumption by management that employees on the project already buy in to the change and have the prerequisite knowledge/skills to contribute to the work. Unfortunately, project are often compromised by unexamined assumptions made about this group.

QUESTION THESE ASSUMPTIONS!

It's relatively straightforward (not easy!) to assemble a team of technical and business users to begin design on a new system. What's often overlooked are three assumptions made about employees who become members of project teams:

They see participating on the project as an opportunity.
They are eager to learn new skills to supplement their knowledge of the business.
They're prepared for project style work.

Let's examine each one.

DO THEY PERCEIVE THE PROJECT AS AN OPPORTUNITY?

Employees with subject matter knowledge are a critical balance to external technical consultants who have successfully implemented elsewhere. In the best case, the project is seen by the employee as an opportunity to grow into a more productive role in the organization. However, the criteria used to evaluate their participation often focus exclusively on knowledge, while ignoring their motivation for participating. Regardless of his or her business knowledge, an employee who has not articulated a desire to grow professionally can find him or herself in a difficult place on a project team. Project work can easily become a burden to someone who sees it merely as more work. Ask candidates to articulate goals for themselves as a result of being on the team. They will either come up with how participating will benefit them and the organization, or will reveal that it's not the right fit. The bottom line is, pick project team members carefully and evaluate their participation based on attitude as well as knowledge. Remember, skills can be taught while attitudes are much harder to change.

DO THEY KNOW WHAT THEY DON'T KNOW?

No one comes into a project with everything he or she needs to be successful. Most people, regardless of their skills, know enough to get their work done and avoid developing skills beyond what's necessary. Project work requires a broad range of professional skills that demands recognizing personal strengths and weaknesses.

It may be technical, accounting, business, relationship, organizational, or conceptual thinking. Whatever the area, project work requires everyone to broaden what he or she can and cannot do well. It's not just incumbent on the individual to uncover their strengths and weaknesses. Management needs to make it clear that the project's success is dependent on individuals recognizing and articulating skills they don't possess to be a more effective contributor to the effort. Some of these skills can be taught, but the first step is acknowledging what they are.

RESULTS VS. TIME PUT IN

Project work is organized chaos, something that most people find uncomfortable. Ask people about their first project and you'll hear how unprepared they were for the long periods of inactivity and confusion, quickly transitioning to deadlines that required unexpected evening and weekend work. It's a marathon that can be exhilarating as well as emotionally and physically challenging. Employees who are accustomed to being managed closely may find it a rude awakening a month into the project when no one has yet given them marching orders. Project work requires a fine balance of self-direction and teamwork, skills that employees often do not need to perform in their regular jobs. Minimally, employees should understand the stages that project members goes through, starting with unstructured teams while the plan is being designed to overnight, being expected to work independently while working toward unreasonable milestones that keep changing. Some thrive on this way of working. For others, this is the last thing they ever wanted. Before signing them up, your employees should be aware of what to expect around the nature of project style work.

PERMISSION TO OPT OUT

The best way to prepare your employees for transition onto a project is to inform them of the elements described above, then provide a genuine opportunity to opt out. You can help the employee determine this choice by administering a self- assessment that uncovers their strength and weaknesses around project work.

From this assessment, you may be able to identify skills that can be developed through other training programs, books, etc. The key is identifying the areas for improvement and letting them be part of the choice. Project work requires individuals to take responsibility for their participation. This is not an easy task, especially when the project builds momentum in the later stages. The choice to remain positive in attitude and effective in action cannot be forced on someone. With knowledge of the challenges ahead, along with permission to not participate, employees have a much better shot of rising to the occasion and discover the opportunity associated with being an effective project team member.

Presentation Tip

When using PowerPoint, get rid of slide transitions and sound effects. They become the focus of attention and distract the audience from your message. Even "builds" (lines of text appearing each time you click the mouse) can be distracting. Use simple "builds" only when you're certain that reading ahead will cause your audience more confusion than displaying the entire slide at once.