Project Management | Enterprise Architecture in Higher Education

Helping your team be effective … the role of a Duty Analyst

Sep 262009

I am writing about a topic that came up this week when working with my colleagues at the University of Alaska Office of IT. A common challenge all IT Service teams face delivering projects when there are huge operational demands. Here is the approach we took to address this critical and ongoing challenge in my Business Application Services team in IT Services, BCIT.

In Sept 2007, I took over as the Manager, Business Application Services at BCIT. For the first 4 months, I took a meet, listen and ask approach. I held one-on-one interviews with each of my team members (23 systems analysts in 3 teams). I setup regular meetings with all our key client stakeholders (Registrar’s Office, Finance, HR, Financial Aid, Student Services, Facilities, Alumni and others) around BCIT. I needed to hear from my team and our clients about the challenges they faced and their perceptions of our effectiveness in meeting commitments.

In all the meetings and interviews, I heard a common theme from…

My team: “We have too much to do and can not keep up with the demand from our clients.”
Our clients: “Your team is working hard but we have important projects that are not getting done on time.”
Me: We also had a growing list of application project requests and struggled to keep our key technologies current.

What struck me was the my team was having a significant challenge separating operational work like break fix, small enhancements and regular changes related to business cycles like applying new tax rates from underway project work and deliverables. Operations always trumped project work and the result was delayed or late projects and worse unhappy clients.

We are commited to ensure our core services (operations) are delivered based on our commitments in our IT Services Core Service Catalogue. How could be ensure that we met our service levels in operations and put a focus on delivering on our project commitments??

Separate operations work from project work was the answer.

An opportunity presented itself in January 2008, a systems analyst in our developer team stepped up and took on a new role … the Duty Analyst. The role of the Duty Analyst was to handle all the operational work for a time period freeing up the rest of the developer team to focus on project work relatively uniterrupted. The introduction of the Duty Analyst has made significant improvements on the effectiveness of our developer team.

So what is the role of a Duty Analyst?

Since we have been strong adopters of the ITIL Framework and processes, we already had a process for dealing with incidents (break/fix, small enhancements and regular changes like tax updates). Incident Management is the primary duty of the Duty Analyst. This frees up the rest of the systems analysts/developers to focus solely on project work. Read more...

Gartner’s Emergent Architecture – Is this really a new approach?

enterprise architecture, it governance, itsm, strategic planning 11 Responses »

Aug 152009

On August 11th, Gartner announced a “new approach for enterprise architecture” that they labelled “Emergent Architecture”. I got a chance to read some responses from Todd Biske, Mike Rollings, and Dion Hinchcliffe. Thanks for the great insights and commentary.

In the press release, Bruce Robertson, Gartner Research VP states the two characteristics of “Emergent EA”:

“Architect the lines, not the boxes – which means managing the connections between the different parts of the business rather than the actual parts of the business themselves.”
“It models all relationships as interactions via some set of interfaces, which can be informal and manual”

On characteristic 1. is if you only look at the connections between parts of the business, how can you look for opportunities to reduce complexity, increase efficiency and implement reusability? I believe enterprise architecture is about the whole organization and its environment, not just pieces of it. As an example, our EA practice encompasses IT Service Management (ITIL), Business Analysis (BA) and Program Management (PMO).

On characteristic 2. , again all this says to me is to take a “user experience” approach to describing the architecture. This is nothing new as far as I can tell … perhaps I am missing something?

Now to look at the 7 properties that differentiate “emergent architecture” from “traditional EA”. Read more...

Non-deterministic – “… decentralize decision making to enable innovation”. I don’t see this as anything new. We address this with our technology lifecycle and our technology governance models. We ensure our architecture has a place for innovation in the R&D phase of the technology lifecycle and in the Innovative area of our technology governance.
Autonomous actors – “… devolve control to constituients”. Being that we grew our EA practice out of IT and that I was a one person team, I never was able to “control all aspects of architecture”. Working collaboratively, within a technology governance framework allows autonomy based on funding, support and impact our practice influenced the architecture adopted by our community. Again, I do not see how this is different from our existing EA practice. Implementing data stewardship in our business areas is an example of autonomous acting within our EA.
Rule bound actors – “… define a minimal set of rules and enable choice”. What EA practice has not started with some set of guiding principles? Enabling choice is fundamental within an architecture as long as it respects the established guiding principles. I blogged on this here and here.

EA Communication Plan Development

education, enterprise architecture 24 Responses »

Jul 202009

Serge Thorn wrote an excellent post called “Development of an Enterprise Architecture Communication Plan“. I really enjoyed the read and completely agree that communication is a key success factor for the success of any enterprise architecture practice.

In the post, Serge set the stage by making a case for why a communication plan is key:

“Communication significantly impacts how IT is perceived by the organization, and therefore it plays a crucial role in the successful positioning of IT as an internal partner.”

“Effective communication is part of the overall plan for management of an Enterprise Architecture Program.”

Next, Serge lays out the key steps in developing an EA Communication Plan with supporting artefacts:

Stakeholder General Communication
General Information Needs
General Communication Tools
Communication Matrix
Communication Planning
Implementation Steps

Building on Serge’s post, let’s explore how we create communication plans in IT Services at BCIT. My colleague, Dave Cresswell developed a template for project communication plans that we use for communication planning for large projects and our ongoing strategic practices like enterprise architecture, project/program management and business analysis. I will explore the steps to creating the plan next.

The communication plan template considers the following categories:

Audience
Communication Channel
Message Type
Time (calendar)

Think about the audience for your communication plan first; some examples are:

Executive/Project Sponsors
Institutional Leadership and Management
Project Team
Institutional Stakeholders – students, faculty, staff, alumni, employers
Industry Peer Organizations

Now list the message types like:

general communication
project status reporting and completion
milestone achieved announcement
request for information
service standards
policies
procedures

Third, list the communication channels. Here are some examples:

email – announcements
meetings – 1 on 1 conversations, department & information
presentations
reports/white papers / publications
website
workshops – focus groups

Time is the last category and the most intuitive tool is to simply use a calendar. You need to decide if this is an ongoing communication plan or one built for a project with a start and an end.

Now that you have populated items into each category, its time to match them up to form the plan. Let’s use a simple example for project status reporting. Read more...

Match communication channels to message types. An example would be (message type) Project Status reporting could be delivered via (communication channels) email and websites.
Next match message types to audiences. An example would be Project Status reporting should be delivered to (audience) the Executive/Project Sponsor and the Project Team via email and to stakeholders via a website.