Friday, January 23, 2009
Responses to: Effective I.T. Alignment
This post is an e-mail exchange in response to a previous post "Effective I.T. Alignment." Chip is my friend that gave me permission to post his words here.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Chip:
It has always struck me that, in general, IT wants to be invited to the table by the business rather than earning and then taking a seat at the table. And unless there is the rare, pre-arranged commitment from the business to incorporate IT into the business strategy, IT is very hesitant to take action out of trust and faith. So it becomes difficult to motivate a group based on hope and faith, encouraging them to take risks in a risk-adverse environment.
In my opinion, a responsibility of the leader, is to jump start the change by taking risks, making some mistakes, surviving the mistakes, publicly acknowledging the mistakes, and then continuing on. This shows the rest of the team that risks and even mistakes do not necessarily equal personal or career distress. Ultimately, change will only take place when the leaders internal to the company own it and live it.
So, if you are not at the table then you are on the menu. Choose to be at the right table, take risks, prove everyone wrong, and surround yourselves with those who believe in you.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Wesley:
Your thoughts about Trust and Faith are right on. Trust is something that is earned and I.T. departments that are in a maintenance mode find it hard to trust the business when they step out of the traditional role. I.T. wants to hunker down in their comfort zone and hope they are not noticed. This works for a time while the business is growing. It is not until the business runs aground that they go looking for an I.T. department partner and find a pasty, white skin,
growth stunted group of people. Now, all of the sudden, I.T. is desperately needed and they are not ready to move into action.
I.T. also remembers back to when they were innovating for the business and getting ignored or having funds removed in mid development. There is little to trust in and small amounts of faith that this business need they are being asked to step into is real.
What makes all of this change, as you pointed out, are leaders that take risks. It matters not if the risk is a success or a failure. Success moves the cause forward by building trust. Failure becomes a teachable moment that allows for hope to grow. It is on this hope that the courage for another risk taking event is built. As there are more risks that pay off, the trust and faith get built back. And on this trust and faith is built the partnerships that lead to alignment.
Tuesday, November 11, 2008
Effective I.T. Alignment
This is a link to a summary of the original MIT Sloan article:
Avoiding the Alignment Trap in Information Technology.
By: David Shpilberg, Steve Berez, Rudy Puryear and Sachin Shah
http://www.bain.com/bainweb/Publications/newsletter_detail.asp?id=26136&menu_url=newsletters.asp
This article addresses the idea that before I.T. can truly align with the business goals they must become effective with where they are currently. The “trap” happens when the I.T. group is highly aligned with the business and not very effective at producing desired deliverables. It is important to note the order of these two: Effectiveness comes first and alignment comes second. Here are some additional thoughts I have from this article:
The article does not address the leadership required to develop and increase the effectiveness of the I.T. department. I believe a change agent from within the I.T. department must develop compelling reasons to move from the maintenance philosophy to a “well-oiled” strategy (see four square chart in article). The hardened culture in a maintenance driven I.T. department is difficult to change because the priorities are to keep the business running. Anything beyond that is viewed as superfluous and in the way of supporting the business. This change must be driven from within the I.T. department. An element of excitement and focus needs to be ignited around a common vision that will push the team to a better place than where it is currently. It takes a strong leader to paint a clear path to the future state of operation and change the culture to focus on business alignment.
Once the I.T. department is effectively implementing projects, there must be a realization by the business that investment in the stale, aged I.T. infrastructure is required. Most business divisions are looking for quick returns. In the case of I.T. infrastructure, the returns may not be seen for several years. This poses a difficult choice for business units.
There will be a point in the business evolution that growth will stop because the infrastructure cannot keep up with the demands of the business. In as much as the internal I.T. culture must change, the business must re-image the I.T. department as a partner worth investing in. This re-imaging will become a synergistic pull that will add to the I.T. department’s push. The process will accelerate and the returns will happen faster than expected thus prompting more infrastructure investment. It is this push/pull/invest cycle that will turn the maintenance culture into one of innovation that adds true value to the business. In the end, the whole corporation wins when there is effective alignment of I.T. with the needs of the business.
Avoiding the Alignment Trap in Information Technology.
By: David Shpilberg, Steve Berez, Rudy Puryear and Sachin Shah
http://www.bain.com/bainweb/Publications/newsletter_detail.asp?id=26136&menu_url=newsletters.asp
This article addresses the idea that before I.T. can truly align with the business goals they must become effective with where they are currently. The “trap” happens when the I.T. group is highly aligned with the business and not very effective at producing desired deliverables. It is important to note the order of these two: Effectiveness comes first and alignment comes second. Here are some additional thoughts I have from this article:
The article does not address the leadership required to develop and increase the effectiveness of the I.T. department. I believe a change agent from within the I.T. department must develop compelling reasons to move from the maintenance philosophy to a “well-oiled” strategy (see four square chart in article). The hardened culture in a maintenance driven I.T. department is difficult to change because the priorities are to keep the business running. Anything beyond that is viewed as superfluous and in the way of supporting the business. This change must be driven from within the I.T. department. An element of excitement and focus needs to be ignited around a common vision that will push the team to a better place than where it is currently. It takes a strong leader to paint a clear path to the future state of operation and change the culture to focus on business alignment.
Once the I.T. department is effectively implementing projects, there must be a realization by the business that investment in the stale, aged I.T. infrastructure is required. Most business divisions are looking for quick returns. In the case of I.T. infrastructure, the returns may not be seen for several years. This poses a difficult choice for business units.
There will be a point in the business evolution that growth will stop because the infrastructure cannot keep up with the demands of the business. In as much as the internal I.T. culture must change, the business must re-image the I.T. department as a partner worth investing in. This re-imaging will become a synergistic pull that will add to the I.T. department’s push. The process will accelerate and the returns will happen faster than expected thus prompting more infrastructure investment. It is this push/pull/invest cycle that will turn the maintenance culture into one of innovation that adds true value to the business. In the end, the whole corporation wins when there is effective alignment of I.T. with the needs of the business.
Labels:
Effectiveness,
I.T. Alignment,
Leadership,
Projects
Tuesday, September 23, 2008
The Best Part... Project Closure
Oddly enough Project Closure is my favorite phase in project management. I like it because it is the formal transition of the work from creation to production. Closure is the acknowledgement that something new and unique now exists. This is the place where the emotions that built up during the project are released and the team can survey their success. Or in the case of a failed project, closure is the formal understanding by the team and all of the stakeholders that the effort is over and it is time to leverage the lessons learned and move forward.
For me closure is personal, quiet and introspective where my heart smiles at the success of the team or I study the issues around failure so I do not repeat them.
For me closure is personal, quiet and introspective where my heart smiles at the success of the team or I study the issues around failure so I do not repeat them.
Tuesday, September 2, 2008
Preparation + Opportunity = Luck
I believe luck happens when preparation intersects opportunity. We call it luck because we do not know when this intersection will happen. Powerful and magical things happen when you are ready to handle events that cross your path.
- Someone who has prepared their life saving skills by learning CPR has the powerful opportunity to act in a crisis.
- Someone who prepares, develops skills or acquires new knowledge can act on career opportunities when they are presented.
So do you want to “Change your luck?”
Then start preparing and growing and learning. Opportunities may be facing you right now that you cannot see. They are unseen because you are not prepared to accept what is ahead. A new skill or new piece of knowledge may open your vision to see the intersection. It is like aligning the rain and the light to see a rainbow. What a lucky thing!
So start preparing. Watch out for opportunities in your life. Your preparations will open your eyes to places where your knowledge and skills can be applied. You will start finding the opportunities and opportunities will keep finding YOU!
Tuesday, July 15, 2008
So you want to be a Project Manager
This blog posting was originally composed in a Project Management Case Studies class. We discussed the qualifications of a Project Manager and how to become a PM. After some thought this was my response posted on the class discussion board.
* * * * *
The discussion in class about how to become a PM was very good. I am sorry if I was not much help. Maybe I can color in a few things here.
The skills of a PM are part art and part science.
The art part includes things like people skills, intuition, leadership, communication skills, psychologist and Den Mom. Being able to diffuse a project crisis with in the team or between stakeholders. Building relationships of trust across functional areas and with in the project team. These are the soft skills.
The science of being a project manager involves the technical “stuff” in the PMBOK: Making a Gantt chart and knowing how to use it in a project. Calculating CV, SV, CPI and SPI (PMBOK page173 – 174). Being able to identify scope creep and stopping it. Building budgets and resource plans. Being able to negotiate with vendors for material and resources. These are the technical skills.
Then there is the passion for the practice of Project Management. You have got to love it and breathe it in all you do, work and home. You have got to love taking the risk of being project owner/leader. You crave walking the line between the terror of failure and the exhilaration of success. You are willing to take a public bullet for the team and then step out of the spot light when your team pulls it off in the extra mile. You learn from failure and celebrate success. You always desire to become better and raise people up in the process.
This is the art and science of Project Management in my view. So… You still want to be a Project Manager? How do you make it happen…?
You just do it. Every project around the house use something new from the PMBOK. Judge your performance by the number of trips you make to Home Depot before your project is complete. Do PM at work. Write a brief scope statement for the latest assignment the boss gives you. Make a WBS and build a time line. Then follow it. Calculate where you actually are relative to the plan. Make adjustments. Learn the technical “stuff” of PM.
Be around senior Project Managers. Watch them in meetings, deconstruct their communications. Ask questions. Work into a PM position starting as a Project Coordinator. Become a member of PMI and volunteer to run a project for the chapter. (This is where I saw great project management modeled.) Set the goal of becoming a Certified Project Manager (PMP). Get project management input through books, magazines and the web:
Cornelius Ficthner has a podcast titled “Episode 62: How Can I become a Project Manager.” This link should get you to the podcast:
http://www.thepmpodcast.com/index.php?option=com_content&task=view&id=109&Itemid=9
Thomas Cutting writes a wonderful blog of PM lessons learned and techniques that are beneficial to him:
http://www.cuttingsedge.com/
I believe luck happens when preparation intersects opportunity. So start preparing and watch out for opportunities to be a project manager. Your preparations will open your eyes to places where the science can be applied. And as you apply the science you will improve your “artistic” skills of managing projects.
Go for it!
* * * * *
The discussion in class about how to become a PM was very good. I am sorry if I was not much help. Maybe I can color in a few things here.
The skills of a PM are part art and part science.
The art part includes things like people skills, intuition, leadership, communication skills, psychologist and Den Mom. Being able to diffuse a project crisis with in the team or between stakeholders. Building relationships of trust across functional areas and with in the project team. These are the soft skills.
The science of being a project manager involves the technical “stuff” in the PMBOK: Making a Gantt chart and knowing how to use it in a project. Calculating CV, SV, CPI and SPI (PMBOK page173 – 174). Being able to identify scope creep and stopping it. Building budgets and resource plans. Being able to negotiate with vendors for material and resources. These are the technical skills.
Then there is the passion for the practice of Project Management. You have got to love it and breathe it in all you do, work and home. You have got to love taking the risk of being project owner/leader. You crave walking the line between the terror of failure and the exhilaration of success. You are willing to take a public bullet for the team and then step out of the spot light when your team pulls it off in the extra mile. You learn from failure and celebrate success. You always desire to become better and raise people up in the process.
This is the art and science of Project Management in my view. So… You still want to be a Project Manager? How do you make it happen…?
You just do it. Every project around the house use something new from the PMBOK. Judge your performance by the number of trips you make to Home Depot before your project is complete. Do PM at work. Write a brief scope statement for the latest assignment the boss gives you. Make a WBS and build a time line. Then follow it. Calculate where you actually are relative to the plan. Make adjustments. Learn the technical “stuff” of PM.
Be around senior Project Managers. Watch them in meetings, deconstruct their communications. Ask questions. Work into a PM position starting as a Project Coordinator. Become a member of PMI and volunteer to run a project for the chapter. (This is where I saw great project management modeled.) Set the goal of becoming a Certified Project Manager (PMP). Get project management input through books, magazines and the web:
Cornelius Ficthner has a podcast titled “Episode 62: How Can I become a Project Manager.” This link should get you to the podcast:
http://www.thepmpodcast.com/index.php?option=com_content&task=view&id=109&Itemid=9
Thomas Cutting writes a wonderful blog of PM lessons learned and techniques that are beneficial to him:
http://www.cuttingsedge.com/
I believe luck happens when preparation intersects opportunity. So start preparing and watch out for opportunities to be a project manager. Your preparations will open your eyes to places where the science can be applied. And as you apply the science you will improve your “artistic” skills of managing projects.
Go for it!
Labels:
career,
preperation,
project management,
project manager
Monday, February 26, 2007
Wikis and Blogs Transforming Project Management
This link goes to an interesting article about how Wikis and Blogs can change the workflow of a company. I thinks there is application to managing projects.
http://searchcio.techtarget.com/originalContent/0,289142,sid19_gci1184607,00.html
As a project manager, I see real value in using both in project work. I like the idea of using a Blog for communicating the project status to the team and the stakeholders. The monologue with comments becomes a place where stakeholders can pull information about the project when ever they need it. Traditionally the PM pushes out information to the team. I also like the idea of having the whole project history in one place. The helps to centralize the "story" of the project and collect lessons learned for the application in the next project.
Wiki’s are a great collaborative tool. When you have a team that is separated by time and or geography, I can see how working on a project schedule in a wiki would be valuable. Each member can input the expertise into the schedule listing tasks and durations. In the end there is a complete schedule that has the whole team buy-in. Other PM areas can benefit: Risk assessments, Quality feedback, an RFP process, even laying the ground rules for the project could be hammered out in a wiki. Even a project team that is local can benefit by working together… Project the Wiki on a screen in a conference room and take meeting minutes, document assumptions and capture “group think.” Then when the meeting is over, the team can continue making additions as ideas come to mind, everyone can access the information during their project work, and the team collaboration that was started in the meeting can continue.
The interesting thing here is transparency. If used correctly there are no hidden thoughts, no undocumented assumptions and no project surprises. These two tools allow stakeholders to look inside the project as it is happening. The stakeholders can interact with the project by commenting, asking questions, encouraging the team, etc. While the stakeholder is "watching" the inter-working of the project, they are validating the scope... "Is this what I really wanted as my deliverable?" If not, corrections can be made as early as possible in the planning or execution phase. If the deliverable is right, the stakeholder is able to watch its development and have a deeper understanding of how the use and deploy the final deliverable. There is an early "bonding" of the stakeholder to the project deliverable that will reduce the chances of the deliverable being rejected at birth.
Unlike the traditional status report that is e-mailed out every Friday and not read, the Wiki and Blog put the ownership of getting the project information on the stakeholder. Any time an update is needed (even if it is not Friday) a stakeholder can get an update. This is important... these tools may keep the stakeholder from calling or e-mailing the PM, using up both of their valuable time. And in the e-mail scenario, the stakeholder is waiting for a response from the PM, when they could have checked the Wiki or the Blog for an up-to-the-minute project status.
Yes the PM is responsible for keeping the tool(s) update. I would submit, however, that the PM can push some of the administration work of updating to the project team. The team members can input up-to-the-minute information on the status their tasks on the WBS. They can report successes and road blocks. In most cases the PM is calling, meeting with or e-mailing the team members. Then the PM is reforming the information from the team into a status report for the stakeholders. This takes a lot of time on the part of the PM and the team.
The same project status information, kept more current, in a conversational medium, accessible anytime, created with team buy in, that saves time and improves communication efficiency is worth trying.
Good luck with your try and let me know how it work for you.
http://searchcio.techtarget.com/originalContent/0,289142,sid19_gci1184607,00.html
As a project manager, I see real value in using both in project work. I like the idea of using a Blog for communicating the project status to the team and the stakeholders. The monologue with comments becomes a place where stakeholders can pull information about the project when ever they need it. Traditionally the PM pushes out information to the team. I also like the idea of having the whole project history in one place. The helps to centralize the "story" of the project and collect lessons learned for the application in the next project.
Wiki’s are a great collaborative tool. When you have a team that is separated by time and or geography, I can see how working on a project schedule in a wiki would be valuable. Each member can input the expertise into the schedule listing tasks and durations. In the end there is a complete schedule that has the whole team buy-in. Other PM areas can benefit: Risk assessments, Quality feedback, an RFP process, even laying the ground rules for the project could be hammered out in a wiki. Even a project team that is local can benefit by working together… Project the Wiki on a screen in a conference room and take meeting minutes, document assumptions and capture “group think.” Then when the meeting is over, the team can continue making additions as ideas come to mind, everyone can access the information during their project work, and the team collaboration that was started in the meeting can continue.
The interesting thing here is transparency. If used correctly there are no hidden thoughts, no undocumented assumptions and no project surprises. These two tools allow stakeholders to look inside the project as it is happening. The stakeholders can interact with the project by commenting, asking questions, encouraging the team, etc. While the stakeholder is "watching" the inter-working of the project, they are validating the scope... "Is this what I really wanted as my deliverable?" If not, corrections can be made as early as possible in the planning or execution phase. If the deliverable is right, the stakeholder is able to watch its development and have a deeper understanding of how the use and deploy the final deliverable. There is an early "bonding" of the stakeholder to the project deliverable that will reduce the chances of the deliverable being rejected at birth.
Unlike the traditional status report that is e-mailed out every Friday and not read, the Wiki and Blog put the ownership of getting the project information on the stakeholder. Any time an update is needed (even if it is not Friday) a stakeholder can get an update. This is important... these tools may keep the stakeholder from calling or e-mailing the PM, using up both of their valuable time. And in the e-mail scenario, the stakeholder is waiting for a response from the PM, when they could have checked the Wiki or the Blog for an up-to-the-minute project status.
Yes the PM is responsible for keeping the tool(s) update. I would submit, however, that the PM can push some of the administration work of updating to the project team. The team members can input up-to-the-minute information on the status their tasks on the WBS. They can report successes and road blocks. In most cases the PM is calling, meeting with or e-mailing the team members. Then the PM is reforming the information from the team into a status report for the stakeholders. This takes a lot of time on the part of the PM and the team.
The same project status information, kept more current, in a conversational medium, accessible anytime, created with team buy in, that saves time and improves communication efficiency is worth trying.
Good luck with your try and let me know how it work for you.
Labels:
Blog,
Knowledge Management,
project management,
wiki,
Work Flow
Monday, February 12, 2007
Knowledge is the Fuel, Intelligence is the Engine
This morning on my commute I was listening to the Motley Fool Podcast interview of A.J. Jacobs. Mr. Jacobs went on a quest to become the world’s smartest man by reading the whole encyclopedia. He has written a book called “Know-it-all.”
http://www.podcastdirectory.com/podcasts/3179
In this interview Mr. Jacobs comments that “Knowledge is the Fuel, Intelligence is the Engine.” How true this is…
We are living in an environment where knowledge in abundant. Knowledge is created at a pace today we have never seen in all of human history. More than just the creation of knowledge, access to the knowledge is readily available and cheap. The Internet is the prime example of knowledge accessibility. In schools, libraries and our homes we find access to knowledge that exist as well as a view into the “crucible” where knowledge is created. Further, we can jump into the “crucible” at any point to join in the forging of new knowledge. We are at a unique point in human history.
Intelligence is another issue. (http://en.wikipedia.org/wiki/Intelligence) As I look at the world around me I find that intelligence is scarce. I do understand that not every one has the same I.Q. or abilities. We are all different in many ways and that is generally good. However, when people are faced with the simplest of knowledge, they do not know what to do with it. There is a blankness or paralysis when faced with knowledge. There is a lack of taking the next step (that only humans can do) and discovering insight and developing an opinion and then making actionable decisions. It is in the place where these actionable decisions are created that work is done, money is made and lives become simpler.
We humans seem to be developing tools that can handle and process more and more knowledge, but we as humans are not evolving our intelligence fast enough to keep up with the processing. We need more capacity to make useful decisions with the available data. So we build a faster and bigger computer (with our knowledge) that can turn data into information and crunch information into knowledge. But what are we doing with this knowledge? Are we now creating knowledge for the sake of creation? Have we created such a stockpile of “Fuel” that our “Engines” will never burn it all?
I’m glad Mr. Jacobs you are the smartest man in the world, truly I am glad. Why? Because now I know that I am not the smartest man in the world and that takes a lot of pressure off.
Now, what are you going to do with all that knowledge?
http://www.podcastdirectory.com/podcasts/3179
In this interview Mr. Jacobs comments that “Knowledge is the Fuel, Intelligence is the Engine.” How true this is…
We are living in an environment where knowledge in abundant. Knowledge is created at a pace today we have never seen in all of human history. More than just the creation of knowledge, access to the knowledge is readily available and cheap. The Internet is the prime example of knowledge accessibility. In schools, libraries and our homes we find access to knowledge that exist as well as a view into the “crucible” where knowledge is created. Further, we can jump into the “crucible” at any point to join in the forging of new knowledge. We are at a unique point in human history.
Intelligence is another issue. (http://en.wikipedia.org/wiki/Intelligence) As I look at the world around me I find that intelligence is scarce. I do understand that not every one has the same I.Q. or abilities. We are all different in many ways and that is generally good. However, when people are faced with the simplest of knowledge, they do not know what to do with it. There is a blankness or paralysis when faced with knowledge. There is a lack of taking the next step (that only humans can do) and discovering insight and developing an opinion and then making actionable decisions. It is in the place where these actionable decisions are created that work is done, money is made and lives become simpler.
We humans seem to be developing tools that can handle and process more and more knowledge, but we as humans are not evolving our intelligence fast enough to keep up with the processing. We need more capacity to make useful decisions with the available data. So we build a faster and bigger computer (with our knowledge) that can turn data into information and crunch information into knowledge. But what are we doing with this knowledge? Are we now creating knowledge for the sake of creation? Have we created such a stockpile of “Fuel” that our “Engines” will never burn it all?
I’m glad Mr. Jacobs you are the smartest man in the world, truly I am glad. Why? Because now I know that I am not the smartest man in the world and that takes a lot of pressure off.
Now, what are you going to do with all that knowledge?
Subscribe to:
Posts (Atom)