Do you start the day opening your email and looking at the hundreds or thousands of messages in your Inbox?  How does that make you feel? Overwhelmed, stressed and feeling like you are always behind on your commitments?

Do you have days where you know you worked very hard but somehow have nothing to show what you accomplished?  How does that make you feel? Unproductive, overworked and stressed?

Do you feel that everyday you are at the beck and call of everyone else and do not have any control of what new crisis will hit you next? How does that make you feel?  Dis-empowered, helpless and always wondering what the next crisis is?

These three symptoms typified my work life since I became a manager almost four years ago.  I often said to my fellow managers:

“I am working really hard but it is not sustainable to do 10 and 12 hour days.  I have to find a way to work smart so that my hard work really pays off!”

I attended a training course on using Outlook 2010 in May that has fundamentally changed how I approach my work.  The course was offered by Priority Management Systems Inc and called Working Sm@rt with Microsoft Outlook.   The course focused on using Outlook as a real productivity tool instead of using it just for email and calendaring. The instructor calls this “using Outlook with a business planning approach”.

The premise of the course is that in order to be productive, you need to focus on your commitments.  To do this, you have to stop using your email Inbox as your To Do list.  Face it, who puts things in your Inbox?  You or other people.

As long as you start your day working in your Inbox, you will always be reactive in your efforts and working to someone else’s agenda.

To change this approach, the instructor helped us configure out Outlook client to open in our calendar and task list view.  This is revolutionary for me.  Previous to this, I used my Inbox, a paper based Day Timer journal, a Notepad document, a OneNote page and an Excel spreadsheet to try to keep To Do lists.  None actually suited how I worked and I always found that I missed something or got distracted by conflicting priorities due to using multiple lists.

 

I have the privilege of leading a great group of IT professionals at the British Columbia Institute of Technology. Part of my role is to help my team members think about and plan for their careers. I wrote about an approach using Personal Learning Plans that contributes to my thinking about this topic.  I also added my thoughts to something Chris Lockhart (@chrisonea) wrote called The Right Stuff in a post called Building on the Right Stuff.

I had two sessions over the past weeks helping intermediate systems analysts think about where they should focus their efforts in their learning plans and about their future career paths.  I introduced both people to our thinking about the types of people that are needed in every organization (in our case in IT organizations).

We started by talking about some of these continuum that influence careers:

  • Individual vs Team
  • Follower vs Leader
  • Technical vs Functional
  • Departmental vs Enterprise
  • Specialist vs Generalist

I firmly believe you need to know yourself before you can determine the paths you will take.  I suggested to both team members to take the Myers-Briggs tests to get a clearer sense of themselves.  Taking this approach also allows us to have a common vocabulary when talking about personality attributes.  Take a look at my blog post Being a Teacher Works for Me.  I suggest you take the test and see if it matches your perception of yourself.   I will write another post that builds on the next step of our discussion by looking at what attributes we should work on.

 

I scanned my Twitter feed on Monday May 16th and found a post by Todd Williams called The Progressive CIO’s Model for Project Success.  After the last couple of months of having to put our IT Services PMO team in place to rescue “business” led projects, I am compelled to question approach proposed by Todd.

Todd makes the point that IT organizations have been unsuccessful in building systems that meet their customer’s needs and fail in schedule, usability and scope.  This is a true statement as long as it is taken in context.  These symptoms of project failure (note: I did not say IT failure!) represent organizations that have a low levels of IT and Project Governance in their IT departments and in the rest of their organization.  Todd suggests that “progressive CIOs” need a new approach which is opposite to today’s practices.

I disagree … progressive CIOs need to recognize that IT touches all parts of the organization and that IT is one of the only places in a company where a broad enterprise view can be well understood and supported. Growing and maturing a PMO (project,program,portfolio mgmt) in IT is the first step.  Then moving that mature PMO out of IT to serve the entire organization should be the mission of a progressive CIO.

Next Todd suggests that because a business unit can use MS Office tools like Excel and Access to build small departmental applications on time, schedule and budget that we in IT should consider handing this work back to the business and concentrate on infrastructure.

If the user is better at creating useful applications and IT builds better infrastructure, then create an organization to mimic that model.

This is a huge generalization and does not come close to the complexity and scope of what an enterprise system project can entail. I will have to write a different post about the massive technical debt that our organizations carry due to all these departmental systems built with Microsoft Office tools!

There is a reason for having specific departments in organizations and that is to deliver on their specialized services.  Human Resources should deliver HR services.  Finance should deliver financial services.  IT should deliver IT services.  PMOs should deliver project services.  Creating redundant Project Management services and IT implementation services in multiple departments adds cost, complexity and creates silos within organizations.  Another big problem is this approach causes issues in departments that end up relying on individual experts who get sick, go on vacation, on training or leave the company.  This makes the department vulnerable to not being able to deliver on service commitments to the organization.  The level of risk of not being able to deliver a key departmental service is not something any senior leader should accept for their organization.

© 2007-2012 Enterprise Architecture in Higher Education - Leo de Sousa Creative Commons License
Enterprise Architecture in Higher Education by Leo de Sousa is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
Based on a work at leodesousa.ca.
Suffusion theme by Sayontan Sinha

Switch to our mobile site