Building a teaM
Some situations might require more expediency to meet budget cycles, social popularity, and
organizational changes. If you do need to move quickly to capture a window of opportunity,
keep these basics in mind:
First, don’t forget to scale (at any phase) through virtual teams. As John Heywood said,
“Many hands make light work.”
Second, be sure to prioritize based on impact. It might be more effective to integrate ele-
ments of your program into existing, well-established programs initially.
Finally, keep a regular line of communications open with all your stakeholders. Some
internal marketing will go a long way and can be as simple as regular, well-authored, and
Ultimately, your PM will own the project cadence. As program lead, you will need to oversee
the main milestones to be sure they are realistic. Part of this process will be working regularly
with multiple virtual team members. A good practice is to set up regular strategic reviews of the
project’s timelines. The strategic planning of how the program develops might not be covered by
your PM, but can inﬂuence your delivery dates. Keeping the strategic direction clear, relevant, and
timely across the many teams with whom you are working will ensure a successful project pace.
Building a Team
True motivation comes from achievement, personal development, job satisfaction, and
At this point in your program’s development, you can begin to partition your stakeholders from
your functional team members. This is where the real, functional work begins that will require
tangible support, both human and ﬁnancial. Through your benchmarking efforts, you should
get a sense from the facilities, IT, and ﬁnance teams as to the popularity of your concepts. This is
your ﬁrst feedback point to consider when thinking about who to ask for project team support.
Balancing stakeholders and contributors will be important to your project’s overall success.
When separating your stakeholders from your functional team, be sure to remember who
is the client and who is the vendor. Although not necessarily formalized, you are the architect
and program manager of a new service. In this analogy, you are the vendor. For IT, which likely
does not pay the power bill directly, jumping to a new service without a proof of concept and
pilot is probably a nonstarter. Facilities and ﬁnance departments might be more receptive to a
more formal exploratory project. You should anticipate that you might need to complete your
proof of concept and possibly your pilot without direct support from IT.
The structure and skill set of your team will be predicated on the scope of your proof of con-
cept and pilot. If you follow our example and focus only on IT assets for the ﬁrst phase of your
program, you will need primarily IT skill sets. To bring together the team focused on the largest
power-consuming domains of IT assets today, you can refer back to your benchmarking data.
You need to focus on whoever are the largest consumers. As you get through your asset-level
benchmarking, you will uncover what energy goes to what platforms. If you’re big on servers
607251c04.indd 105 8/25/10 12:32:26 PM