Last week, I presented the accomplishments of my applications team in 2009. I was blown away by the number and the scope of the projects my team delivered to our community. I firmly believe that the separation of our operational duties from our project work enabled us to be so productive. While most people would celebrate the project teams |(and we do!), I want to acknowledge the key enabler of this success – our Duty Analyst role.
I blogged previously about our Duty Analyst role here.
Implementing a duty analyst role minimizes the operational interruptions to our team members working on projects. Providing project members focused time to work on project challenges and meeting milestones becomes easier without operational interruptions.
I am proud to say my team delivered on our operational responsibilities and completed 43 projects in 2009.
Here is the breakdown of projects my team delivered: Read more...
- Projects by Size : Small = 19, Medium = 14, Large = 10
- Projects by Governance : BCIT Executive = 3, IT Governance Team = 14, Business Applications Committee = 5, Departmental = 11, Operational = 10
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… Read more...
- 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.”
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? Read more...
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
- Communicaton 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. Read more...
Alan Inglis posted about What good looks like from a solutions architecture perspective. How do you create a solution for a new project without creating architecture that already exists or making the same mistakes that previous projects made? This is a must read post and I recommend it.
Alan described 10 artefacts that he would expect a solutions architect to leave behind from a project implementation. They are:
- Project Background
- Terminology
- Key Drivers, Principles, Standards and Constraints
- Business Problem
- Information View
- Risk View
- Application View
- Data View
- Integration View
- Infrastructure View
I have some questions for Alan on this:
- How big a project would require this level of artefact creation? For small and possibly medium projects, the work to do the architecture may be more than delivering the project.
- Is there a subset of these artefacts that would be sufficient for small and medium projects?
- How would the next solutions architect find and assess the artefacts created? Need a searchable, secured repository – wiki?, blog?, SharePoint?, network file share?, knowledge base?
We, Enterprise Architects, regular trumpet the value of having an archictecture and learning from it. Some of the key factors for me would be: Read more...
We are interviewing candidates for the Manager of our Program Management Office this week. These unfortunate economic times seem to generate a high number of quality applicants. Not so good for them but really good for us.
I approach an interview as an opportunity for the selection committee and the applicant to learn from each other. Learning about applicant’s experiences and the organizations they work in provides insight into what is going on in industry. Recently, we began asking our applicants to make a short presentation. This is a great way to see how the person communicates concepts and ideas as well as handling questions.
Inevitably, there are always gems that the person communicates. When I hear them, I write them down, take back the idea to my team to implement quickly. Here are some ideas: Read more...
- When an item in a project status report goes to a “yellow” state, only let it remain there for two weeks. Either it is resolved and moves to “green” or it needs more attention and moves to “red”
- Sometimes you run a project using “plexecution” which means you doing planning and execution at the same time … we do this a lot!
In this post, I will describe the IT governance committee for small and medium projects, their terms of reference and the scoring system for ranking projects. In September 2007, we started a process to use IT governance to help us manage the flood of proposals and project requests. Thanks to my colleagues Gary Lake and Dave Cresswell who did the heavy lifting and put the process in place.
The Business Applications Advisory Committee (BAAC) gives advice and guidance to IT Services on which project requests would be the “right things” to do; recognizing that we have limited resources and want to focus them on the work that will deliver the most value to our community.
BAAC Terms of Reference
Business Application Advisory Committee advises Information Technology Services on the priorities for small to medium sized business application proposals that will further the goals and strategies of BCIT.
We define two types of business application projects: Major and Minor. Major projects are referred to the BCIT Executive Leadership team for governance. Minor projects are referred to the BAAC for ranking.
Minor projects are defined as: Read more...
- projects that will improve BCIT business processes and are not part of routine maintenance or operational activities of IT Services