Month: February 2011
The Three Roles of a Leader
As leaders (in IT and otherwise), our job consists of three roles:
- Identify new opportunities for the organization, team or group to add business value. This involves building, maintaining and leveraging relationships with various stakeholders within the business and facilitating regular back and forth communication and dialogue between business operations resources and your own business technology resources. As leaders, we are expected to be on the lookout for the team to ensure we identify opportunities and exploit them to our business partners’ best interests.
- Remove obstacles and barriers to success. This means either obtaining resources, facilitating discussions, or making a phone call to make a problem go away. As leaders, we are the final point of escalation and our teams are counting on us to make problems go away. We are expected to always be communicating and maintaining relationships that will enable us to be a resource to our teams when they encounter barriers to execution.
- Preserve, Protect and Defend the teams’ culture. This means ensuring that the team HAS an identifiable and USEABLE culture that is focused on execution, delivery and sound core values that resonate within the team and can be used not only to guide the team from a long-term strategic perspective, but from a day-to-day tactical perspective. As leaders, we are expected to make the difficult decisions regarding resources – whether hiring, coaching or firing – to ensure that the team’s execution and delivery-focused culture remains intact.
By focusing on these three key activities, we not only serve our teams and their best interests in adding value to our business, but we also build and maintain a solid partnership with our business operations colleagues in helping them gain and keep a competitive edge.
© 2011 – Mark E. Calabrese
“Business Agility” by Mike Hugos
I’m currently reading Mike Hugos‘ Business Agility. I met Mike at a Technology Executive Network (TEN) meeting in Chicago late last year. The point of the book is to introduce the idea of applying Agility principles to the business world and not just to software development. Mike makes a good case as to how this can be done but more importantly, he points out WHY it makes sense – especially given how quickly companies must adapt to ever-changing customer needs. I’m not finished with the book yet, but I think it’s worth the read.
Mike is a very interesting guy, who bills himself as a ‘CIO at Large’ and runs the Center For Systems Innovation (c4si). We’ve had a few discussions (somewhat convenient that he just lives a few blocks down the street from me) and I have to say that I’m glad I met him. I owe Phil McEntee, who runs TEN, a ‘thank you’ for the connection.
You can read Mike’s blog here. Mike also write and blogs at CIO Magazine and Computerworld.
Getting Your Team To Develop Goals Aligned With Your Strategy
We’ve all seen this before. We ask our teams to develop individual goals that are aligned to corporate strategy, but we find that our teams are trying to force-fit their own personal goals (read: things they want to do, irrespective of corporate strategy) into the strategy framework. In other words, if you have a team member who really wants to take a Java class, but there’s no link to that objective and to achieving the desired technology component to the corporate strategy, you need to get that team member aligned appropriately while still helping them achieve their own goals in the context of business operations.
This is symptomatic of our not providing clear leadership, tying strategic goals back to regular day-to-day tactical life; basically showing how real work RIGHT NOW is tied to strategic goals. Try this framework on for size and see if it works for you. It’s a take (maybe?) on the ‘Three Step Plan’, though I have to confess that apart from Andy Willoughby’s website, which is pretty much content-free, I still have no idea what the ‘3 Step Plan’ really is:
ONE Message – Evangelize!: Once you’ve rolled out the strategic roadmap, giving the presentation, handing out t-shirts and the like, you need to be an evangelist for the roadmap on a DAILY BASIS. That means that you seek to put most events, work, issues and opportunities within the framework of the roadmap. If the business strategy changes, so should the roadmap as well as the gospel you’re preaching. The aim here is to get your team to understand that: 1.) the roadmap is REAL and it isn’t going anywhere’ 2.) that the roadmap is a regular topic of conversation, as it has a strong relationship to every day real work; and 3.) that you take it seriously.
TWO Questions to Ask: Ask these two questions about every goal proposed by your team: 1.) What business problem will this solve?; and 2.) How will things be different tomorrow after you’ve achieved this goal?
THREE Workstreams: There are three workstreams in business technology in which the strategy needs to be realized in the form of tactical objectives and individual goals: 1.) Day to Day Production Support and Issue Resolution or ‘Lights On’; 2.) Projects and Initiatives or ‘New Development’; and 3.) Policy and Procedures. There is no ‘fourth workstream’ called ‘Strategy’. Any strategy must be executed in one of these three workstreams. Make sure your teams understand this and that they develop their tactical objectives within this framework.
One last word on measurement. Ask each team member to define the OBJECTIVE measure by which they’ll know that their goal was attained. The key here is ‘objective’ and I use the following example to make the point.
Your team member should choose a measure that, if you (the boss) were to be hit by a bus the week before reviews are due, that there would be NO QUESTION as to whether the goal was achieved or not. No one can argue that 2+2 doesn’t equal 4; it’s another matter if you’re stating that you’re going to do a “really great job” at something. Quantify it where you can and leave no mistake as to whether the goal was achieved.
In an upcoming post, I’ll talk about developing strategic roadmaps and tying them to actual day-to-day life for your teams. As always, comments and emails on this and other posts are always appreciated!
© 2011 – Mark E. Calabrese
Automating PMO Workflow
Lately, I’ve noticed that a lot of organizations are seriously considering purchasing tools to automate their PMO workflow. While there are certainly some good products out there worth considering, I think it’s important to avoid the “rush to automation” as a solution to all problems. Automation doesn’t solve every problem, so it’s always a good idea to initially approach the problem using a version of the following framework BEFORE committing company resources to the purchase, installation and integration of a PMO or project workflow tool:
- Understand the Current State: Clearly define the current project workflow. Make sure you not only document and understand the PUBLISHED workflow, but how it actually works in practice. If there’s a gap between the processes and practices in the current state, things will only get more complicated as you try to move to a defined future state.
- Understand, Clarify and Document the Future State: Make sure that the desired future state is clearly understood and documented. This will become important when you sell the idea internally, as well as when you begin to gather and document requirements. Make sure that there is agreement on the future state among all stakeholders – business AND technology. EVERYONE has to agree on what “tomorrow” looks like or you’ll be setting yourself up for another host of interesting complications.
- Gap Analysis – Part I: Perform a gap analysis of the Current and Future states and DOCUMENT WHAT YOU FIND. This will serve two purposes, as I’ll point out below.
- Analyze and Improve the Current State Workflow: Before building out your requirements, looking up and talking to vendors or scheduling demos, stop for a moment and determine whether your existing workflow is optimal. Can some of the problems be resolved by simply improving the existing workflow and avoiding the expense of finding and implementing an automated solution? As advisors to our business partners on how they invest their IT dollars, it is incumbent upon us to make sure that the PMO workflow we intend to automate is optimal in the CURRENT STATE. Avoid the idea that “we’ll improve the workflow when we implement the new solution”. You may find that optimizing the current solution will be enough to meet the business’ needs.
- Implement the Improvements: Once you’ve identified ways to optimize the existing workflow, implement the changes. Make sure you’ve captured any metrics as a baseline so that you can test the improvements to see if they deliver the desired changes. If they do, then you’ve resolved a business operations issue at minimal cost. If the changes do NOT yield the desired results, at minimum you’ve not only improved the existing process that will be automated, but you’ve shown your business partners that you treat their IT investment as YOUR investment, too.
- Gap Analysis – Part II: Now that you’ve optimized the existing workflow, perform the gap analysis between the new and improved Current State with the Future State. This should result in a set of RFP-ready requirements that can be used in vendor selection and as a basis for the implementation and integration effort.
Remember that as IT leaders, our mission is to deliver products and services that meet or exceed our partner’s business needs and to ensure that we advise them such that they NEVER waste their IT investment.
© 2011 – Mark E. Calabrese
mec. musings 