2. Agenda
• Enterprise IT
• IT Governance
• IT Portfolio Selection And Management
Methodologies
• Making the Business Case
• Project Management at NYCHA
• PMO Automation
More…
1/15/06 2
3. Why is this an important topic?
• Fiscal realities dictate selective IT investment
• Technology/tools chosen need to support the business
problem/challenge or opportunity
• Project management should guarantee that the
selected technology works, the business problem has
been solved, and the investment was contained
• Projects utilizing technology should support improved
business processes and therefore be led by a business
owner
• Business owners shouldn’t have to be professional
project managers
1/15/06 3
4. How To Balance IT and Business
Drivers: Client Funded Model
IT Client
Infrastructure Business
Costs Value
Drivers Drivers
1/15/06 4
5. How does an Enterprise IT Structure Fit?
Business Challenges:
• Project requests are often “siloed” resulting in
limited benefits to the organization
• Requests address only a slice of an end-to-end
business process
• Projects aren’t supported by a strong and consistent
business case often resulting in unclear scope
and/or failed completion
• Multiple technology platforms and solutions
supporting similar business functions in different
departments, are expensive and inefficient to support
More…
1/15/06 5
6. Enterprise IT Structure Example
Mapping IT Support to Business Objectives
Effective Vision, Objectives,
Strategic Plans
Business and IT Business Results
Collaboration
Processes, support, and
Infrastructure tools that enable business Application
functions
Services Development
Supporting Enterprise
Project
Foundation Architecture
Management
Accountability
Discipline
Metrics More…
1/15/06 6
7. What is IT governance?
As Defined by Gartner:
• IT governance provides a framework in which the decisions made
about IT issues are aligned with the overall business strategy and
culture of the enterprise
• Governance is concerned with setting directions, establishing
standards and principles, and prioritizing investments.
• The process of assigning decision rights is influenced by corporate
culture, business orientation, stakeholders' opinions and the
knowledge required of decision makers.
• Effective it governance involves the assignment of decision-making
rights and accountabilities regarding behavior in the desirable use
of it.
1/15/06 7
9. Why is a Portfolio Approach Relevant?
• An organization must understand its goals,
have a flexible process to determine priorities
based on changing environments, and select
projects that will provide meaningful
improvement to:
–Customer satisfaction
–Employee productivity
–Business process improvements
–Cost take-out from the operating budget
1/15/06 9
10. Portfolio Management Approach –
Ongoing Process
Portfolio
Management
GM
• Portfolio scope
• Prioritize& optimize overall IT cost, benefits, risk
• Actively monitor Portfolio performance
• Adapt to business environment changes Quarterly
Annual
Portfolio
Planning
Program Reviews
Management
• Comprehensive program planning
• Change and risk management
• Coordination of project delivery Monthly
• Measurement of results Program
Quarterly
• Corrective actions Reviews
Planning
Project
Management DGM
• Deliverables
• Initiate Weekly
• Scope
• Budget
Monthly Project
Planning
• Risks Reviews
• Schedule
PM
• Measure More…
• Resources
1/15/06 10
11. How to select the enterprise portfolio – Before
Key Care-Abouts Investment Criteria
• Identify key stakeholders who
•Identify criteria for IT investment:
run the business
improve business process, save
• Understand their goals and money, break-down business
priorities, what keeps them up at
silos, etc.
night, and what gets in the way of
•Apply criteria against list of
doing the job that supports their
goals potential projects
• Use this knowledge to brainstorm
potential IT solutions
Business Case
Enterprise Solutions
•Identify executive sponsor and
• Look for patterns among project manager from the business
solutions of all stakeholders
•Project manager completes a
interviewed
project concept document
• Identify opportunities to
•Project concept documents are
implement one solution for
multiple functions or department presented to IT governance
committee for selection
1/15/06 11
12. How to select the enterprise portfolio - After
Step One: Step Three:
• Started with NYCHA's published “5 year • Six categories of aggregation emerged:
plan for fiscal years 2005 – 2009” as – Compliance
submitted to HUD
– Cost takeout/employee productivity
– New partnerships
• Extracted business goals from these
– New revenue
plans and hypothesized on Executive’s
– Nycha-wide initiatives
business goal correlation and
opportunities – Resident care
• Each goal was analyzed based on the key
impact areas of people, process, & technology.
• In partnership with NYCHA's CFO
Goals where technology could play a role were
conducted 1:1 sessions with DGMs to
identified and presented to the GM who
validate business goals, key success
requested a policy planning offsite
metrics and solutions, in the context of
spring financial planning – 60 solutions
resulted
Step Four:
• Building on all of the above planning and using
Step Two: the same planning matrix as step one –
portfolio methodology was developed
• Results Were Aggregated & Refined After
a Review with the General Manager • Impact categories were refined:
• Example: – Customer satisfaction
Hugh Spence – DGM for Community Operations
– Resource enhancement
1. One Voice Portal
2. Automated DOH Licensing Information – Financial savings
3. Automated Social Services Case Management
• Information sets such as: category, sponsoring
4. Resident Employment Training & Tracking System
department, forecasted cost & benefits, & FTE
5. Community Center Internet Connectivity NYCHA project resources were presented in
6. Reduce Duplicate Function – Community Center chart, graph & pivot table format to enable a GM
Construction Operations review of 26 projects for prioritization
1/15/06 12
13. Application & Solutions Portfolio – NYCHA Today
Step Five:
• Balancing resource impact, risk, funding,
departmental involvement & customer
improvements, A tiered approach was
developed by the General Manager
• Application / Solution Portfolio
• Tier 1 Top Priority Business Initiatives
• Tier 2 Emerging Business Initiatives (business case
this year)
• Tier 3 Managed by IT (limited or no business PM
involvement)
• Tier 4 Future Year Initiatives
1/15/06 13
14. How to Make the Business Case
• Elevator pitch: what is the business problem, challenge
or opportunity? Why should the executive care?
• Describe in layman’s terms a credible potential solution
• Define metrics that will show the executive that the
solution has successfully addressed the business
problem/challenge/opportunity
• Document the cost of doing business the current way v.
the new way that the solution will promote
• Compare to best practice examples
1/15/06 14
15. Business Case Components
Project Team and Stakeholders Project Approach
• Executive Sponsor • Estimated Project Resource
Requirements
• Project Owner/IT Partner
• Implementation Approach
• Impacted Personnel
• Estimated Duration of
Business Context
Implementation
• Business Problem
• Procurement Recommendations
• Business Goals
Cost/Benefit Analysis
• Business Functional Objectives
• Methodology and Analysis
• Metrics
Results/ROI
Proposed Solution • Estimated Project Cost
• Solution Description • Funding Source(s)
• Alternatives Considered
Risk Management Plan
• Rational for Selection
• Barriers
• Product Selection
• Probability of Risk
• Consistency with IT Strategy
• Mitigation Strategy
1/15/06 15
16. The Goal of the IT PMO Discipline at NYCHA
Provide the end-to-end project
delivery and project management
processes, standards, best
practices, and tools to enable the
organization to achieve far higher
levels of performance, rapidly
delivering big wins with positive
financial impact.
1/15/06 16
17. PMO Roles
Project Coach
Project Repository
• Best practice sharing across
• Source of information on project
organization functions and
methodology and standards
coordinates communication
• Facilitates the use of a cohesive
• Raises organizational
set of tools for project design, performance -- mentoring
management and reporting relationships may be established
across business boundaries
• Empowers distributed, business-
between high and low performing
centric project ownership
project managers
• A first step to enfranchise the idea
• The PMO is a permanent structure
of consolidating or sharing and has some supervisory
management practices but does responsibility for all enterprise
business projects
NOT provide direct project
• A quot;dotted linequot; reporting
management
relationship from business-staffed
project managers and to the CIO
1/15/06 17
24. How to Scale a PM Standard Throughout the
Enterprise: The Role of Automation
• Project Dashboard
• Knowledge Management &
Collaboration Repository
• Planning/Tracking
• Risk Management
• Reporting/Issue Management
• Automated Compliance
1/15/06 24
25. PMO: Project Dashboard
•Overview: The Virtual IT PMO: a
comprehensive view, defined by user Illustrative
role, for all the news and information
about NYCHA projects
•Users: Project team, executive
sponsors and anyone who needs to
learn more about the projects, or
need to know about status
•Elements: Workflow navigation
that guides the project manager
through the required project lifecycle.
Provides current project status,
project plan and timeline, issues and
risks logs, and link to repository
which stores past status reports and
other project-related information.
•Owner: PMO
1/15/06 25
26. PMO: Collaboration Space
•Overview: A common repository for all
Illustrative
project related document storage and
collaboration facilitation
•Users: PMO, project managers and
team members, and anyone needing
access to knowledge management
•Elements: Contains current and
historical documents and completed PMO
templates, past status reports, updated
issues and risk logs, etc. Provides version
control and authentication. Information
clearly segregated in open and protected
folders with links provided to any other
required website (e.g., NYCHA intranet).
•Owner: PMO with project managers for
their specific folders (collaboration spaces)
1/15/06 26
27. PMO: Planning/Tracking
•Overview: The overall detailed,
activity-based plan for the project using
Microsoft Enterprise Project Server
•Users: PMO, project managers and
delegated team members, steering
committee, executive sponsor
•Elements: Planning and tracking
information in Web-based views as
detailed a view as selected by the user.
Information comes from Project Server.
Data is hierarchical and can be expanded
or collapsed to view a snapshot of the
entire project. This is what feeds the
dashboard.
•Owner: Project managers maintain the
ownership of each plan
1/15/06 27
28. PMO: Risk Management
•Overview: Automated Compliance
to Ensure Risk Management Plan
Adherence and Regular Review
•Users: Project manager leading their
team, executive sponsor, other
executives
•Elements: List of all the project risks,
their severity, impacted areas, likely
impact (delay, budget increase) and
mitigation strategies. Starts in Initiation
Phase to populate the required
documentation throughout the lifecycle,
includes the risk management plan, risk
log and status reports.
•Owner: Project managers
1/15/06 28
29. PMO: Reporting
Automatically Completed for
•Overview: A set of templates to you!
report the status of the project and (can be edited)
Illustrative
overall portfolio throughout the lifecycle
•Users: PMO, project managers,
steering committee, executive sponsor,
governance committee, CFO, Board
•Elements: InfoPath templates, SQL
database and web-based reporting.
Project level template for each project.
Three status reports depending on the
audience - includes an overall
red/yellow/green status assessment with
the high level explanation followed by
major accomplishments, key issues and
upcoming milestones.
•Owner: Project Manager with PMO
review on monthly and quarterly reports
1/15/06 29
31. More from Agenda Slide: NYCHA Historical Context
Let’s talk about some of the environmental factors that were in place almost three years ago, when the new CIO first
thought about the establishing a formalized governance structure. The fiscal realities that presented themselves
when he started, and what he saw in the technology environment in April of 2002:
At NYCHA, our primary issue was the lack of an overall information-technology governance process, and that
manifested itself in a variety of ways. One was that projects that got supported and funded were identified through
a specific line of business, and not considered in its enterprise sense. So if a business owner had a particular
need for a technology-support tool, that tool was built specifically for that business owner without any
consideration for the overall enterprise requirement. Historically, the application of that process, created a series
of business applications that were not integrated -- they were siloed with respect to support, and with respect to
the delivery of the solution. A specific line of business then had its own platform, its own business application, and
its own relationship with the technology-support organization. And, even its own IT staff.
This would be repeated across the various lines of business, so the result was seven or eight different computing
platforms, multiple technology solutions that run on those platforms, and staff that was dedicated to support those
various platforms and solutions. The initial objective was to reorganize the technology organization into a full
enterprise support and service organization by removing these silos, but also recognizing that over time that we
would continue to have some of these specific platforms that would need to be supported.
We wanted to create a single technology organization that considers the primary support requirements in terms of
technology infrastructure and business-application support.
At the same time, it became very clear that the fiscal situation at NYCHA was indeed changing. Funding that NYCHA had
been accustomed to throughout the years, primarily from HUD, had essentially dried up. And so we had to come up
with ways to make a decision, about how technology investments could be leveraged across multiple business
requirements within the enterprise.
So, for example, there should not to be a separate inspection system for each line of business, but rather an enterprise-
wide inspection system that would support each line of business. And as a means to that end, three things
occurred: the creation of a project-management process; the reorganization of the technology organization; and
putting into place a governance or a technology-investment consideration and support structure that would govern
the process going forward.
To summarize, there are a lot of culture-change factors occurring at the same time. So, it actually was a challenge, but
also a terrific opportunity. On the one hand, we were going from a system within NYCHA, that allocated funding for
projects based on individual requests that came in, and individual analysis of these requests, to a process where
departments had budgets, budget responsibility centers, financial planning, (encumbrance)-based budgeting, and
the like. And all of this was happening at the same time that we were implementing a comprehensive, enterprise-
wide financial-management system. So that was one major opportunity.
Back
1/15/06 31
32. More from “How Does Enterprise IT …Fit” Slide:
When you don’t have a clear project-management process in place you get lots of different information -- requesting
the same thing. So, here you might be an executive who has to make a funding decision, and you really don’t
know what you’re getting because everyone who’s submitting a request for a project is submitting different
information. A t the end of the day you don’t have to be a technology expert. If someone comes to you with a
request for project and spends all that time talking about the technology and this is not an area that you’re
familiar with, how comfortable are you going to be in making a decision to fund a project?
What’s good about having a consistent project-management discipline is that each project manager is guided by a
consistent set of questions to, let’s say, make a business case. So the business case ends up being stronger.
It’s more consistent. This addresses the challenge that we had historically where the scope is unclear, the
project maybe failed in completion. One example, anecdotally, was $15 million allocated to some sort of human-
resource management system, and all the $15 million was spent but at the end of the day we only yielded $1
million in functionality, if you really look at the scope, because it was unclear. There was no consistent process.
There was no consistent approach, but all the money was spent.
Finally, when you address funding of IT requests independently of each other without a clear enterprise structure,
you end up with all these multiple technology platforms, performing perhaps similar business functions in
different departments, and you’re not developing the benefit of having one solution where staff is trained to run
that solution that multiple departments can use. The opportunity to accomplish all of this today is that the chief
information officer position was created at NYCHA . If it existed before, it really existed in title, not in reality,
and it certainly wasn’t at the deputy general manager level. Why that’s important is, ostensibly we’re a very
large organization, a large corporation, if you will, that’s run by a general manager who reports to a board. The
general manager is like a CEO, and underneath him he has executives, deputy general managers, there are
seven of them, that really are responsible for the day-to-day operation of this large corporation.
In creating the chief information officer at the deputy general manager level, you’ve basically made the chief
information officer a peer to all the executives who are responsible for running the authority. That’s significant
because, not only does that position now have the clout to implement and champion and effectively coach this
sort of discipline, but they have a seat at the table where all these policy decisions are being made, so they have
more insight into the primary business goals of the enterprise.
It shows what an important role technology is playing within this organization. A t the end of the day, this all starts
from the top. It’s embraced bottom-up, but it comes top-down, and that’s very significant. It’s very significant
for this to be considered as important as any other initiative in the enterprise. In addition, because there wasn’t
this process of stating what services were required, what technology was going to do, it was very fragmented, it
was distributed across different organizational silos, people just handed things off. People didn’t know what
other business units did, and lost the opportunity to collaborate and have a more effective solution.
A nother result is that when you have a bifurcated enterprise IT organization, there is no proper expectation on
behalf of the customer of the type of response they’re going to get, the time that they’re going to get their
response addressed, the hand-off that they’re going to get to three other people to address what is a very
straightforward request or need from the IT organization. There is no good issue resolution or tracking of
issues. Most importantly, there isn’t a good balance between what the need is from the customers for service,
and what the capabilities are of the organization to actually address and support those services.
In that type of environment there is an inability to actually measure costs and the benefits relative to what’s being Back
provided- to be able to make a good decision as to whether or not we could provide the services internally or we
should go externally.
1/15/06 32
33. More from “Enterprise IT Structure Ex. Slide
Why was this organization put in place, what are the important elements and why?
The primary driver for implementation technology has to be a sound business plan and an effective
vision for where the organization is headed. On the basis of that type of plan, a technology
strategy can be developed that effectively aligns with that plan. In order to carry out the
technology strategy, the organization has to consist of infrastructure support and development in
the growth of the infrastructure, and at the same time the development of the business solution.
To govern that organization model, what’s needed is an effective process and discipline to
manage technology initiatives, and have a clear blueprint of the technology architecture that
would evolve to support the overall strategy.
What we ended up with are two operational units: an IT infrastructure group and an application-
development group. These are the two groups that are responsible for the operations of IT,
meaning the day-to-day programming, the day-to-day support of hardware, software, etc. Then,
above that, as the policy-making organization, the coordination, the administrative organization,
is the office of the CIO. Within the office of CIO is this function that we’re talking about today,
this project and information-management function, with this virtual PMO process, the IT
governance, the project-portfolio selection and management, the project-management discipline,
but from a virtual sense, meaning setting the policy, the goals, the tones, facilitating, coaching,
orchestrating.
Additionally within the Office of the CIO is an enterprise-technology architect, who is responsible for
really understanding the business goals, but from the technology platform and solution and
standard perspective. Within that function, the quality-assurance function, which you’ll see in our
project-management discipline or project life cycle, we’ve institutionalized the importance of the
role of quality assurance, why it exists in the office of CIO, reporting to the enterprise technology
architect, is it’s important that that quality-assurance function not report to the operations group,
the application-development group of the IT infrastructure group. With this type of organization,
the CIO actually has a better understanding of what the objectives should be. He can
communicate to his staff what his expectations are. There’s more accountability. There’s more
of an understanding of what everyone’s role is within the IT organization, how that rolls up to the
important business goals of the organization. Most importantly, he has a way of measuring all of
Back
this.
1/15/06 33
34. More from “Portfolio Mgmt Approach” Slide
The methodology that we use is coming together. The point at which we select projects comes together at the same time
as the financial-planning cycle, which is new to NYCHA . So that has been a terrific opportunity, to take advantage of
this partnership because of the timing at which they are introducing this whole notion of semiannual financial planning.
Then we have this opportunity to prioritize projects. So we have three types of projects at NYCHA , and to segment
them and to come up with process-reporting requirements, depending on the nature of the project.
When we discussed the client-funded model, that we have central infrastructure projects, projects that are needed to
make sure that we have this robust, scalable, dependable network, and those projects could range anywhere from
introducing a new telephony technology, or upgrading the network operating system, or upgrading the e-mail system,
or standardizing on the server platform, or developing a life cycle for PCs and laptops and servers. A ll of those
projects are projects that our CIO and general manager like to refer to as inside (inaudible). These are things that he
trusts the CIO to decide, that don’t really require much decision and discussion with the other executives, and these
are projects that are going to be managed by IT.
That’s one group of projects where we are not going to bring them constantly before this governing body, which I will detail
in a couple of slides. Then there are very small application-development projects, generally enhancements to existing
applications where we have to make upgrades because perhaps a version of the software is no longer supportable, we
had an audit finding perhaps, perhaps we need to upgrade based on an unsupportable platform to a different one. So
these types of projects we have to do anyway, and really don’t need to, again, have the same sort of in-depth review
by all of the executives.
The group of projects Called the enterprise IT business projects are what constitutes the portfolio of projects that are really
focused on. The are the projects that we prioritize in terms of where we’re going to make the IT investment and what
is going to be reviewed in terms of the entire portfolio. These projects consist of business solutions that are reviewed
quarterly. We’ve now successfully gone through four quarterly reviews of the portfolio. Today’s quarterly review was
Q1 05, which is our fifth quarterly review, and this is an opportunity -- currently we have 12 projects -- we’re probably
going to winnow that down some in the next coming months, since some of our projects that are come on are very,
very large projects. So we need to really bring that number down some.
It’s an opportunity for each of the project managers, again, directors, deputy directors, to come before our governance
committee, which at the very least consists of all our executive sponsors, and give the same review, meaning answer
the same questions of where their project is for the reporting period, which is the previous three months, and do it
together. A ll of the project managers are going to discuss answers to the same questions, the same 90-minute
session, so that the members of the governance committee can get a sense of the portfolio and make decisions about
priorities if they need to. So this is part of our flexible environment.
There should be monthly program reviews with the executive sponsor, where there may be multiple projects that roll up to
an overall program initiative. This gives the executive sponsor a way of understanding where their important program
is going, how the different projects are working within their program, and also to give them more of an intimate
interaction with their project managers on the projects that they’re ultimately responsible for. This is a way that they
can really focus in on what the metrics should be, what results they should measure, and also gives them an
opportunity to take corrective actions when there are some decisions that need to be escalated to them, that the
project team hasn’t been able to resolve amongst themselves. A nd then of course, at the lowest level of the weekly
reviews that are done by the project manager, and that’s the key project management, initiate, budget, schedule,
deliverable scope, risks, resources, measures, and the like.
Back
1/15/06 34
35. More from “IT Governance Example” Slide
The purpose of providing them with support is not to project-manage
the process for them, not to dictate how they go about it, but to
coach them, mentor them, and provide them with tools to help them
move through their important projects’ life cycles. To that end,
every time we go forward with a project where we require the
business manager to -- the project manager to come to the
business -- we give them an IT strategic partner. Going back to the
example that we gave about the new IT organization, this customer-
service approach, this organization can respond to the business
needs of the organization and be effective -- it doesn’t matter what
group they come from. They’re still responsible for any IT need that
their project manager has. So, let’s say it’s the enterprise-
technology architect. Application Development doesn’t report to
him. The IT Infrastructure (ITI) team doesn’t report to him. But he’s
still responsible for getting what’s needed from those groups for
the project manager. So it’s this customer-service approach. And
then finally, this PMO function, this virtual function, is really
responsible for establishing standards, providing tools, developing
the methodology, and of course, they report in to the CIO and also
this partnership with the CFO, you could see this as a dotted line.
Back
1/15/06 35