Executive Patterns: Becoming a Catalyst for Change
Originally Posted Tuesday, June 7, 2011
By: Skip Angel
In our last newsletter, we conducted a poll asking the following question:
“How much executive support do you get for your Agile initiative?”
The results were encouraging, as 36% believed they were getting all the support they needed. The remaining 64% had some support, but could use more. Everyone that participated in the poll indicated that there was at least some involvement by their executives. As a coach having supported the adoption of Agile across several organizations, I usually see one of the following patterns when it comes to executive involvement.
The Impulsive Executive
“Greg” is very reactionary in nature and isn’t afraid to pull the trigger on new ideas. After attending a local class, he gets very excited about Agile. In fact, he decides that he wants to go “all-in” and that all teams should adopt Agile practices ASAP. This isn’t the first time for Greg to react this way, as it seems there is a new initiative coming from him every few months.
At first, it seems things are going well as the teams take on Greg’s mandate. After the newness wears off and the teams start running into challenges, Greg is already off searching for the next new thing. Without his support, it is determined that Agile is too hard and teams are better off doing what they did before. Some people are glad they didn’t commit too much effort to something that isn’t going to stick around. For others, it is just another frustrating “strategic initiative” from Greg and raises concerns about what new changes are just around the corner.
The Laissez-Faire Executive
People like “Jan” because she is very laid back and conservative in her approach. Her answer is always the same, “Do what you think is right”. If teams want to work on their own, so be it. If they want to try out a new methodology, practice or tool, go for it. Under Jan, teams can develop their own standards. It’s all up to them to do “what’s right”. They like the feeling of empowerment, but some team members are overwhelmed with the choices available to them and wish things were simpler.
One of the teams decides to adopt Agile, as its members believe it may be a lighter approach to project management. After struggling a little bit at first on their own, they start to make progress and begin to deliver great results. When they run into problems that they cannot resolve on their own, the answer from Jan is always “make it work”. The team does its best to work around the problems, but the biggest challenge is coordinating with other teams. Since the teams are using different methods, tools, and technical solutions, it becomes very difficult to integrate in order to deliver work together into the production environment. Because they can’t solve this larger problem, the team comes back with the recommendation that Agile would only work for very specific projects that are completely independent. Future projects decide not to adopt Agile because they are considered “too complex” to work with that approach.
The Misguided Executive
“Peter” always believes he is doing the right thing, though he gets frustrated that things don’t always work out the way he intended. Over time, Peter has become a little “gun shy” and is more careful about trying new things without addressing all of the risks. While he is excited about the possible outcomes that Agile could bring to his organization, he has also heard that it exposes potential challenges that need to be resolved.
He creates a group to investigate what needs to be done to do Agile successfully. After several weeks, they come back to Peter with a plan. To ensure success, they need to develop a specific methodology tailored to their organization with all of the best practices and tools that are recommended by the Agile community. Peter agrees to the recommendations and also adds another requirement. To save on potential licensing costs, he decides to start out small with a pilot, just in case it is a failure.
Several more months pass, the group develops the “perfect” methodology and all of the tools are in place. After some basic training on the process, the first pilot team is able to get started. Soon they struggle with how "Agile" works. The methodology is hard to understand and follow, the tools are difficult to fit into the process, and the training results in more questions than answers. Isn’t Agile supposed to be lightweight and focused on delivering software? It seems the team spends more time with the process and tools, leaving little time to deliver anything.
Peter originally thought that with Agile, the team would increase their productivity. After only a couple of sprints, the team has come to a halt. Given that he isn’t seeing the immediate results expected, he decides to terminate the pilot. He bans applying Agile to any future projects because of the significant time and money wasted over the last several months.
The Catalyzing Executive
Like others, “Cindy” is very excited about the benefits that her organization could receive from adopting Agile. However, she also has read enough and received advice from the community that Agile would require a significant organizational change.
Cindy realizes that if this change is going to stick, she needs to become a catalyst. As this catalyst, she knows she needs to provide a sense of urgency for others to buy-in to the idea. She spends time with those on existing projects and helps them see how projects are taking longer, quality is down, and end users are not happy with what is being delivered. She realizes that through these discussions, she is acquiring other champions to further “the cause”. Cindy enlists the help of outside consultants to provide guidance through training and coaching. These coaches focus on reinforcing the principles behind Agile, so that teams can better understand how to adapt the process to get expected results.
Cindy takes an incremental approach to the adoption process by rolling out small waves of project teams at a pace that the organization can handle. She encourages everyone to take chances, try new things, and learn from the results. Cindy works with other managers to address things that are slowing teams down, such as complex processes, a variety of tools, and a lack of big picture thinking. They come up with streamlined automated processes, minimal use of a standard set of tools and technologies, and tighter alignment to strategy through technical and product roadmaps.
Because of Cindy’s efforts, real change is happening in her organization that not only benefits the teams delivering software using Agile methods, but extends to all areas that are learning how adapt to any changes that may come.
Does your executive fall into any of these scenarios?
Perhaps they are like Greg, Jan, and Peter and are less than thrilled with the results of Agile in your organization. Maybe they can learn from Cindy and consider a more direct and active approach to transforming the organization by introducing Agile practices. Want to become a catalyst like Cindy?
Here are some questions that you should explore if you want to change the behaviors needed for Agile to “stick”:
The meaning of success—Does it mean meeting dates and budgets, or delivering on measurable objectives and delighting customers?
Punishment vs. reward—Are people punished for bearing bad news, or rewarded for providing opportunities for learning and improvement?
Competition vs. collaboration—Are they rewarded for heroic efforts in a competitive environment, or for working well with others?
Decision making—Are decisions made by committee, or are they delegated to those closest to the problem?
Time allocation—Is the majority of time spent thinking about what should be done in meetings, or getting the work done?
Isolation vs. group thinking—Are you working in a "heads down" environment, or a place where people can interact and share ideas?
The elephants in the room—Is most of the time spent working around organizational impediments, or removing them?
Multi-tasking—Are team members juggling many projects at once, or are they working on a single, prioritized project at a time?
Time for innovation—Do people have to learn on their own time, or are research, training, and experimentation encouraged?
Click to read more post by Skip Angel
To learn more about the Performance & Quality Improvement Network, other topics and initiatives - subscribe to this blog, follow us on Twitter, visit our website PQI Network
June 7, 2011
Why is IT so reluctant to look at itself?
Why is IT so reluctant to look at itself?
By Patrick Gray | June 2, 2011, 9:48 AM PDT
There is an interesting tendency among IT organizations to be hesitant to looking inward, with a view of improving internal processes, performance, and interactions with other elements of the company. Perhaps since IT is tasked with performing these functions for others, it seems frivolous to expend time and energy internally, when there is always a large backlog of work for the consumers of IT’s services. This is a misguided notion however, and if IT is truly going to sell itself as able to digest, implement, and improve on corporate strategy, it is imperative its own house is in order.
Perception matters
While many are loathe to admit it, perception and appearances matter. Just as one would be hesitant to hire an obviously out-of-shape personal trainer or a tattooed and pierced estate planner, organizational appearance can have a similar effect. At the most obvious, the IT shop whose frontline staff constantly complains about those jerks in “the business” and reflexively answers “no” to any and all requests is not going to be positively regarded. More subtly, the CIO who is in a constant state of panicked chaos, always too busy to talk, and late to every meeting negatively impacts IT’s perception just as badly.Strive for a perception of control, pragmatism, and openness at all levels of your IT shop. The junior analyst should be just as willing to frankly discuss an idea with a business peer, as the CIO should be scheduling regular meetings with colleagues in sales, marketing, operations, and finance. An IT shop that appears to be staffed with a cadre of business professionals will garner far more appreciation than one that seems loaded with propeller-head prima donnas.
Benchmark thyself
Most IT organizations will proudly proclaim they are excellent at benchmarking, producing rafts of charts, graphs, and reports that minutely analyze everything from server uptime and performance, to the cost to send a single email, calculated with seven decimal places of precision. While that is all well and good, few IT organizations effectively track their performance and perception in the larger organization. While knowing technical benchmarks is fine, it is far more valuable to know if the larger company perceives your IT shop as inflexible, incapable, and generally incompetent. This need not be a mind-numbingly complex endeavor, and an external party can perform a basic benchmarking exercise for a minimal investment of “time and treasure.” Furthermore, knowing where you stand and continually monitoring your organizational performance allows you to quantify and measure the results of efforts toward improving your internal practices.Practice what you preach
Nearly everyone in IT talks about improving processes throughout the organization but often ignores its own idiosyncrasies. From eight people being involved in a process that really needs only two, to poor internal management of incoming requirements and project requests, most IT organizations have myriad opportunities to improve their internal processes and systems. Rather than being frivolous or self-centered, making your internal processes more effective creates an IT organization that is more nimble, quicker to respond to changes in the business, and a more enjoyable place to work. The IT organization that is constantly in a reactionary mode is never going to get a seat at the strategy table, nor is it going to be perceived as a valuable asset to the company.While it may seem unsettling to look inward when problems abound outside IT, each hour spent improving your internal practices can pay long-term dividends. With some targeted investments, you can shift your IT shop from a reactionary, “break/fix” driven entity, to one that can thoughtfully approach a business problem, propose a considered solution, and confidently guide its implementation.
Patrick Gray is the founder and president of Prevoyance Group and author of Breakthrough IT: Supercharging Organizational Value through Technology as well as the companion e-book The Breakthrough CIO’s Companion. Prevoyance Group provides strategy consulting services to Fortune 500 and 1000 companies. Patrick can be reached at patrick.gray@prevoyancegroup.com, and you can follow his blog at www.itbswatch.com.
June 3, 2011
Face it: Organizational charts don't work - reposted
Originally Posted on TechRepublic
By John McKee
June 1, 2011, 12:58 PM PDT
Takeaway: Can something as simple as your organizational chart impact the company’s performance? Executive leadership coach says definitely. In this blog, he explains why.
Recently, I was asked to take a look at a client company’s organization chart. It was to be a part of a review on performance and morale. Company management wanted me to review and make suggestions that would help ensure they were accurately depicting their business. After reviewing the first page, I declined.
From experience, I knew it would have been a frustrating exercise (talking to a lot of people and hearing their opinions and recommendations). More importantly, I knew it wouldn’t have resulted in any effective changes within the place. By declining, I chose to look after the client’s expenses. And my sanity.
The company used a traditional pyramidal structure, i.e. boss at the top, next in command on the line below, their underlings on the next level. As far as I can tell, this structure probably started about 5,000 BC with the Sumerian civilization. After they crashed, it was picked up by subsequent generations of leaders — next being the Egyptians about 2,000 BC. It has existed, more or less, in the same style since then.
Given how successful this reporting and management structure was for all the past civilizations, I am not inclined to recommend it to anyone....
There are tons of management studies that support the reasons for not using a structure like this.
Key issues include:
It’s not simply for small companies. The critical factor — that the boss is never more than one step away from the person who’s doing things – can be modified for even the biggest companies. Apple’s structure proves it can work. In that organization, virtually every key area’s leader reports directly to Steve Jobs. Nobody “in charge” of a key area is more than one step away from the boss.
Consequently:
For anyone who really enjoys his or her job, reducing the number of levels will make it more fun — and successful.
John M. McKee is the founder and CEO of BusinessSuccessCoach.net, an international consulting and coaching practice with subscribers in 43 countries. One of the founding senior executives of DIRECTV, his hands-on experience includes leading billion dollar organizations and launching start-ups in both the U.S. and Canada. The author of three published books, he is frequently seen providing advice on TV, in magazines, and newspapers.
To learn more about the Performance & Quality Improvement Network, other topics and initiatives - subscribe to this blog, follow us on Twitter, visit our website PQI Network
By John McKee
June 1, 2011, 12:58 PM PDT
Takeaway: Can something as simple as your organizational chart impact the company’s performance? Executive leadership coach says definitely. In this blog, he explains why.
Recently, I was asked to take a look at a client company’s organization chart. It was to be a part of a review on performance and morale. Company management wanted me to review and make suggestions that would help ensure they were accurately depicting their business. After reviewing the first page, I declined.
From experience, I knew it would have been a frustrating exercise (talking to a lot of people and hearing their opinions and recommendations). More importantly, I knew it wouldn’t have resulted in any effective changes within the place. By declining, I chose to look after the client’s expenses. And my sanity.
The company used a traditional pyramidal structure, i.e. boss at the top, next in command on the line below, their underlings on the next level. As far as I can tell, this structure probably started about 5,000 BC with the Sumerian civilization. After they crashed, it was picked up by subsequent generations of leaders — next being the Egyptians about 2,000 BC. It has existed, more or less, in the same style since then.
Given how successful this reporting and management structure was for all the past civilizations, I am not inclined to recommend it to anyone....
There are tons of management studies that support the reasons for not using a structure like this.
Key issues include:
- they’re always out of date,
- they don’t deal with how things “really” get done, and
- they distance company leadership from the important work of the organization.
I like flat organizations: They work when the boss is involved. And, if he or she isn’t involved, they show that the leader is not up to the task and should be replaced.
It’s not simply for small companies. The critical factor — that the boss is never more than one step away from the person who’s doing things – can be modified for even the biggest companies. Apple’s structure proves it can work. In that organization, virtually every key area’s leader reports directly to Steve Jobs. Nobody “in charge” of a key area is more than one step away from the boss.
Consequently:
- decisions are made faster,
- money is spent according to the priorities of the company, and
- there’s less culture clash internally with fiefdoms being created by each department head.
For anyone who really enjoys his or her job, reducing the number of levels will make it more fun — and successful.
John M. McKee is the founder and CEO of BusinessSuccessCoach.net, an international consulting and coaching practice with subscribers in 43 countries. One of the founding senior executives of DIRECTV, his hands-on experience includes leading billion dollar organizations and launching start-ups in both the U.S. and Canada. The author of three published books, he is frequently seen providing advice on TV, in magazines, and newspapers.
To learn more about the Performance & Quality Improvement Network, other topics and initiatives - subscribe to this blog, follow us on Twitter, visit our website PQI Network
April 19, 2011
Develop a Project Recovery Plan
Originally Posted By Rick Freedman
April 18, 2011 on TechRepublic
Takeaway: Rick Freedman presents a five-step plan for PMs tasked with rescuing a challenged project. He also urges PMs to consider the emotional aspects of project rescue.
I would bet that every project manager (PM) has heard about The Standish Group and it's CHAOS studies (theory), which purport to measure IT project success and failure rates. I say “purport to measure” because these studies, published periodically since 1995, have recently been questioned, especially by proponents of agile development. While the techniques of the CHAOS studies can be argued, most experienced PMs will agree with one of their key points: many projects are “challenged,” struggling to deliver the promised benefits on time and on schedule. The latest CHAOS study, for example, places 44% of projects surveyed in the challenged category.
Many PMs have also experienced the dreaded “project that wouldn’t die,” an initiative that lost its way and careened out of control, but, due to the difficulties associated with admitting failure, limped on for years, wasting resources and careers along the way. Some proportion of projects in the challenged category surely fit this description, and terminating zombie projects is an important topic, but one for another post. In this post we’ll instead examine those projects that, although circling the drain, are worth saving.
Notwithstanding the growth of Project Management Offices (PMOs) and the application of robust project methodologies, projects continue to struggle or fail, with teams, sponsors, and stakeholders denying the calamity staring them in the face. Admitting failure in the business setting is difficult and potentially career-threatening. Nobody wants to raise her hand and tell sponsors that their investment is in jeopardy and that the glowing benefits described during the initiation phase are turning into a heap of ashes. In project rescue, admitting the problem is often the hardest part, but it is the necessary first step to recovery.
Whether a project is on the fast track to success or the road to disaster, the critical measurements of time, scope, budget, and quality still apply. When one or all of these elements is out of whack, our central job in project rescue is to:
Once it has been acknowledged that a project is in trouble, my experience is that an explicit “get well” program is an absolute requirement for recovery. Rather than trying to sneak in under the radar and thus shield the team from scrutiny, a candid admission that the project is in danger and that we’re making a focused effort to set it aright is the only way to begin regaining trust and enthusiasm. Many failing projects have acquired the aura of inevitable disaster, making the rebuilding of belief and positive momentum a deciding factor in recovery. PMs tasked with rescuing challenged projects ignore these psychological aspects at their peril, as many well-intentioned recovery programs have foundered on the rocks of despair and cynicism.
1. Assess the status dispassionately
Projects get into trouble in a variety of areas, from unrealistic budgets and schedules to unexpected technical problems. Some common causes of project difficulty include:
There are as many reasons for project failure as there are projects, and the emotional elements of morale, ego, and self-protection always come into play. It’s one thing for the project to run into unexpected skill-set issues, but it’s quite another for a team member to actually admit that they’re not quite the genius advertised. Team members can usually tell when a sponsor is applying the “make-it-so” style of management, but it’s another to confront that sponsor and deflate their expectations. Project recovery teams walk a fine line in the assessment phase, as we need to recognize and acknowledge these human as well as substantive issues, yet remain neutral and objective so as not to discredit our own findings.
2. Perform a limited “root cause” analysis
Tracing challenges back to causes is critical to the development of a recovery plan, but, again, it is a fraught exercise. The last thing a recovery team needs is to take on the mantle of a “project audit,” which is guaranteed to trigger evasion, secrecy, and protective behavior, rather than the candor required to determine a course correction. Facilitation techniques such as brainstorming, force-field analysis, and pareto analysis can be employed, but, whatever method is used, the key is to retain a neutral, nonjudgmental, and nonthreatening atmosphere.
3. Develop a “get well” plan
The obvious starting point in the development of a project recovery plan is the triple constraint of time, scope, and budget. My experience is that unrealistic assumptions in one of these three areas is the underlying problem in the vast majority of challenged initiatives. Artificial deadlines and budgets, imposed by management fiat rather than by objective analysis, are easy to identify but difficult to adjust, as many corporate cultures encourage the “make-it-so” style of management and the “can-do attitude” of employees. This is where the acknowledgment that the project is in danger of failure is a plus; it enables us to concentrate the mind of our sponsors and remind them that unattainable expectations, far from “making it so,” instead make it fail.
The best recovery plans look at time, scope, and budget as a blank page, avoiding the trap of getting snared in existing assumptions. The best project recovery plans also apply strict risk management to every element of the plan, as poor risk planning is a key cause of failure. Failing projects are orphans; project recovery teams need to re-engage their stakeholders and convince them that this project can be saved. Success must be redefined clearly and often must be scoped down; one of my key questions is “what’s the minimum deliverable required to satisfy the core objectives?” All the project disciplines, from project communication to project change management, must be applied in a consistent manner, and strong leadership is vital.
4. Execute the project recovery plan
Execution of the recovery plan should start with a high-visibility communication program, so that all sponsors and stakeholders know how we plan to rescue this effort and what their role is in the recovery. Without belief and participation, the best recovery plan has little chance. Once the organization is behind the effort, rescue execution, like project execution, is a matter of discipline, consistency, control, and leadership. Since these elements are often missing in challenged projects, it’s especially important that we display them in rescue; stakeholders, even if supportive of the rescue plan, will quickly abandon it if it starts to careen out of control again.
5. Bring the project to closure
Closure and customer acceptance are important in every project. In rescue efforts, their significance is magnified. While few PMs would choose to experience a failing project, the lessons we can learn from them far outweigh those from gleaming success stories. The rescue effort has required the team to discover and acknowledge the causes of failure, making the retrospective that much easier by removing justification and rationalization from the discussion. The learning opportunities afforded by challenged projects are enormous; failing to harvest them is criminal.
Explicit acceptance of the result closes the chapter on the project and gives us an opportunity to remind our stakeholders that even seriously challenged projects can be saved by a healthy application of reality-based planning and consistent discipline. Like a losing sports team that conquers a top-ranked competitor, facing defeat and prevailing can boost confidence and change the dynamic for the better.
Get technology related tips, news, and reviews delivered directly to your inbox by subscribing to TechRepublic’s free newsletters.
To learn more about the Performance & Quality Improvement Network, other topics and initiatives - subscribe to this blog, follow us on Twitter, visit our website PQI Network
April 18, 2011 on TechRepublic
Takeaway: Rick Freedman presents a five-step plan for PMs tasked with rescuing a challenged project. He also urges PMs to consider the emotional aspects of project rescue.
I would bet that every project manager (PM) has heard about The Standish Group and it's CHAOS studies (theory), which purport to measure IT project success and failure rates. I say “purport to measure” because these studies, published periodically since 1995, have recently been questioned, especially by proponents of agile development. While the techniques of the CHAOS studies can be argued, most experienced PMs will agree with one of their key points: many projects are “challenged,” struggling to deliver the promised benefits on time and on schedule. The latest CHAOS study, for example, places 44% of projects surveyed in the challenged category.
Many PMs have also experienced the dreaded “project that wouldn’t die,” an initiative that lost its way and careened out of control, but, due to the difficulties associated with admitting failure, limped on for years, wasting resources and careers along the way. Some proportion of projects in the challenged category surely fit this description, and terminating zombie projects is an important topic, but one for another post. In this post we’ll instead examine those projects that, although circling the drain, are worth saving.
Notwithstanding the growth of Project Management Offices (PMOs) and the application of robust project methodologies, projects continue to struggle or fail, with teams, sponsors, and stakeholders denying the calamity staring them in the face. Admitting failure in the business setting is difficult and potentially career-threatening. Nobody wants to raise her hand and tell sponsors that their investment is in jeopardy and that the glowing benefits described during the initiation phase are turning into a heap of ashes. In project rescue, admitting the problem is often the hardest part, but it is the necessary first step to recovery.
Whether a project is on the fast track to success or the road to disaster, the critical measurements of time, scope, budget, and quality still apply. When one or all of these elements is out of whack, our central job in project rescue is to:
- assess the status of those metrics objectively and dispassionately
- perform a limited “root cause” analysis
- develop a “get well” plan that the entire stakeholder community can believe and support
- execute that plan effectively
- and bring the project to successful closure
Once it has been acknowledged that a project is in trouble, my experience is that an explicit “get well” program is an absolute requirement for recovery. Rather than trying to sneak in under the radar and thus shield the team from scrutiny, a candid admission that the project is in danger and that we’re making a focused effort to set it aright is the only way to begin regaining trust and enthusiasm. Many failing projects have acquired the aura of inevitable disaster, making the rebuilding of belief and positive momentum a deciding factor in recovery. PMs tasked with rescuing challenged projects ignore these psychological aspects at their peril, as many well-intentioned recovery programs have foundered on the rocks of despair and cynicism.
1. Assess the status dispassionately
Projects get into trouble in a variety of areas, from unrealistic budgets and schedules to unexpected technical problems. Some common causes of project difficulty include:
- Technical challenges
- Skill mismatches or deficiencies
- Inadequate or unclear requirements
- Inadequate or unrealistic planning
- Vendor or partner failures
- Methodology weakness or misapplication
There are as many reasons for project failure as there are projects, and the emotional elements of morale, ego, and self-protection always come into play. It’s one thing for the project to run into unexpected skill-set issues, but it’s quite another for a team member to actually admit that they’re not quite the genius advertised. Team members can usually tell when a sponsor is applying the “make-it-so” style of management, but it’s another to confront that sponsor and deflate their expectations. Project recovery teams walk a fine line in the assessment phase, as we need to recognize and acknowledge these human as well as substantive issues, yet remain neutral and objective so as not to discredit our own findings.
2. Perform a limited “root cause” analysis
Tracing challenges back to causes is critical to the development of a recovery plan, but, again, it is a fraught exercise. The last thing a recovery team needs is to take on the mantle of a “project audit,” which is guaranteed to trigger evasion, secrecy, and protective behavior, rather than the candor required to determine a course correction. Facilitation techniques such as brainstorming, force-field analysis, and pareto analysis can be employed, but, whatever method is used, the key is to retain a neutral, nonjudgmental, and nonthreatening atmosphere.
3. Develop a “get well” plan
The obvious starting point in the development of a project recovery plan is the triple constraint of time, scope, and budget. My experience is that unrealistic assumptions in one of these three areas is the underlying problem in the vast majority of challenged initiatives. Artificial deadlines and budgets, imposed by management fiat rather than by objective analysis, are easy to identify but difficult to adjust, as many corporate cultures encourage the “make-it-so” style of management and the “can-do attitude” of employees. This is where the acknowledgment that the project is in danger of failure is a plus; it enables us to concentrate the mind of our sponsors and remind them that unattainable expectations, far from “making it so,” instead make it fail.
The best recovery plans look at time, scope, and budget as a blank page, avoiding the trap of getting snared in existing assumptions. The best project recovery plans also apply strict risk management to every element of the plan, as poor risk planning is a key cause of failure. Failing projects are orphans; project recovery teams need to re-engage their stakeholders and convince them that this project can be saved. Success must be redefined clearly and often must be scoped down; one of my key questions is “what’s the minimum deliverable required to satisfy the core objectives?” All the project disciplines, from project communication to project change management, must be applied in a consistent manner, and strong leadership is vital.
4. Execute the project recovery plan
Execution of the recovery plan should start with a high-visibility communication program, so that all sponsors and stakeholders know how we plan to rescue this effort and what their role is in the recovery. Without belief and participation, the best recovery plan has little chance. Once the organization is behind the effort, rescue execution, like project execution, is a matter of discipline, consistency, control, and leadership. Since these elements are often missing in challenged projects, it’s especially important that we display them in rescue; stakeholders, even if supportive of the rescue plan, will quickly abandon it if it starts to careen out of control again.
5. Bring the project to closure
Closure and customer acceptance are important in every project. In rescue efforts, their significance is magnified. While few PMs would choose to experience a failing project, the lessons we can learn from them far outweigh those from gleaming success stories. The rescue effort has required the team to discover and acknowledge the causes of failure, making the retrospective that much easier by removing justification and rationalization from the discussion. The learning opportunities afforded by challenged projects are enormous; failing to harvest them is criminal.
Explicit acceptance of the result closes the chapter on the project and gives us an opportunity to remind our stakeholders that even seriously challenged projects can be saved by a healthy application of reality-based planning and consistent discipline. Like a losing sports team that conquers a top-ranked competitor, facing defeat and prevailing can boost confidence and change the dynamic for the better.
Get technology related tips, news, and reviews delivered directly to your inbox by subscribing to TechRepublic’s free newsletters.
To learn more about the Performance & Quality Improvement Network, other topics and initiatives - subscribe to this blog, follow us on Twitter, visit our website PQI Network
April 14, 2011
Authenticity - the most important trait of successful leaders
Originally posted: By John McKee
April 14, 2011, 7:38 AM PDT
Takeaway: Many people pay a lot of money to coaching organizations to become better leaders. Executive leadership coach John M McKee says there’s a more effective and less expensive approach.
“John, I need a coach to teach me how to be a leader. I’m good technically, but recently I was promoted to a role I never expected. And, in all honesty, I’m not prepared to lead a team.”
That was a real call I received years ago. I hear a lot of people say similar things all the time. As markets return to prior levels, more organizations are hiring. And more people are getting promoted again. You may find yourself in a similar situation, if you haven’t already.
So, what should you do, if and when you are bumped up the ladder? Is spending money the best first step toward becoming a good leader? I say, “NO!”
And if you think it is the best first step you may end up spending money with a career development organization or individual offering a “program” that’s really just some well packaged canned tips and styles that, while good on paper, may never feel authentic.
And that - authenticity - may be the single most important trait of successful leaders.
It all starts with you being real: Most of us have a kind of radar that alerts us when someone is spouting lines that they don’t believe in. Many studies show that by the time we reach adolescence, we’re already pretty savvy at recognizing BS.
My advice? Before you spend your hard earned money to “learn” how to be a leader, take these steps:
First - make a promise to yourself that you will always be authentic. Keep that promise.
Next - take some time to reflect about the best boss you ever had or witnessed.
Describe him/her to yourself. Write down what attributes come to mind. Noodle on things like:
Of course, your situation may be different. But the key is this:
Start acting like the boss you’d want above you.
Do it using your own, authentic, style.
This will greatly improve your chances of being proud of yourself as a leader. When we’re proud of ourselves, we’re more open to new ideas/less defensive. And success breeds success. In all likelihood, you’ll growand become a better boss.
But what if it doesn’t work? To be straight with you, it may not. In that case, you learn to make “running changes” by modifying your style. Adjust. Test new approaches that resonate with the real you.
If you practice your style consciously and thoughtfully, you will surprise and impress. Both yourself and others.
That’s guaranteed.
- John
John M. McKee is the founder and CEO of BusinessSuccessCoach.net, an international consulting and coaching practice with subscribers in 43 countries. One of the founding senior executives of DIRECTV, his hands-on experience includes leading billion dollar organizations and launching start-ups in both the U.S. and Canada. The author of three published books, he is frequently seen providing advice on TV, in magazines, and newspapers.
To learn more about the Performance & Quality Improvement Network, other topics and initiatives - subscribe to this blog, follow us on Twitter, visit our website PQI Network
April 14, 2011, 7:38 AM PDT
Takeaway: Many people pay a lot of money to coaching organizations to become better leaders. Executive leadership coach John M McKee says there’s a more effective and less expensive approach.
“John, I need a coach to teach me how to be a leader. I’m good technically, but recently I was promoted to a role I never expected. And, in all honesty, I’m not prepared to lead a team.”
That was a real call I received years ago. I hear a lot of people say similar things all the time. As markets return to prior levels, more organizations are hiring. And more people are getting promoted again. You may find yourself in a similar situation, if you haven’t already.
So, what should you do, if and when you are bumped up the ladder? Is spending money the best first step toward becoming a good leader? I say, “NO!”
And if you think it is the best first step you may end up spending money with a career development organization or individual offering a “program” that’s really just some well packaged canned tips and styles that, while good on paper, may never feel authentic.
And that - authenticity - may be the single most important trait of successful leaders.
It all starts with you being real: Most of us have a kind of radar that alerts us when someone is spouting lines that they don’t believe in. Many studies show that by the time we reach adolescence, we’re already pretty savvy at recognizing BS.
My advice? Before you spend your hard earned money to “learn” how to be a leader, take these steps:
First - make a promise to yourself that you will always be authentic. Keep that promise.
Next - take some time to reflect about the best boss you ever had or witnessed.
Describe him/her to yourself. Write down what attributes come to mind. Noodle on things like:
- Was (s)he strong?
- Did he/she show any interest in your personal life?
- Was he/she successful? In both work and personal life, or just one?
- Healthy and/or fit? Or overweight/unhealthy?
- Highly smart, or just average in the IQ arena? (”Life smarts” are not always due to IQ)
- Did that person typically “tell” or “ask”?
Of course, your situation may be different. But the key is this:
Start acting like the boss you’d want above you.
Do it using your own, authentic, style.
This will greatly improve your chances of being proud of yourself as a leader. When we’re proud of ourselves, we’re more open to new ideas/less defensive. And success breeds success. In all likelihood, you’ll growand become a better boss.
But what if it doesn’t work? To be straight with you, it may not. In that case, you learn to make “running changes” by modifying your style. Adjust. Test new approaches that resonate with the real you.
If you practice your style consciously and thoughtfully, you will surprise and impress. Both yourself and others.
That’s guaranteed.
- John
John M. McKee is the founder and CEO of BusinessSuccessCoach.net, an international consulting and coaching practice with subscribers in 43 countries. One of the founding senior executives of DIRECTV, his hands-on experience includes leading billion dollar organizations and launching start-ups in both the U.S. and Canada. The author of three published books, he is frequently seen providing advice on TV, in magazines, and newspapers.
To learn more about the Performance & Quality Improvement Network, other topics and initiatives - subscribe to this blog, follow us on Twitter, visit our website PQI Network
April 6, 2011
Three leadership behaviors of successful Project Managers
Originally Posted By Andrew Makar - TechRepublic IT Leadership Blog Post
April 6, 2011, 7:14 AM PDT
A lot of project management articles focus on technical aspects of the work (e.g., the latest tool, template, or technique to help manage scope, schedules, and people), but it’s just as important to focus on the social and cultural aspects of project management. Leadership, teamwork, negotiation, problem solving, and politics also have a significant impact on a project’s success.
Leadership frameworks can be taught in business schools and professional development courses, though leadership behaviors need to be learned and demonstrated. I once worked for a company that identified three specific leadership behaviors that project managers should demonstrate in addition to successful project delivery. Here’s a look at the three leadership behaviors.
Leadership behavior #1: Demonstrate a drive for results
Project management isn’t easy or filled with glory. The reality is projects are tough and can be stressful, frustrating, and have administrative challenges that can detract from the end goal. Focusing on the tasks that need to be accomplished (regardless of obstacles) and keeping the end goal in mind are easier said than done, but both concepts are critical nonetheless. Effective project managers take responsibility to achieve the results defined by the project; this means you may not be able to simply delegate tasks to others and wait for the status update. On some of my projects, I never thought I’d be the person responsible for data cleanup in legacy systems or have to conduct menial and administrative tasks in preparation for the next day’s workshop; however, sometimes completing menial tasks and focusing on the end result helps move the project forward.
Leadership behavior #2: Demand the truth
In order to make the best decisions, project managers need to know the real issue or risk affecting the project. Effective project managers need to demand the truth from their teams and then present the truth to their management and peers. Minimizing problems and hiding issues with colorful explanations doesn't help the project team or the project manager succeed. By asking team members to explain the status in basic terms without corporate rhetoric or political spin, the entire team will benefit.
Leadership behavior #3: Demonstrate courage
Projects don’t always go as planned, and it’s the project manager’s job to present the current status updates and describe any corrective actions needed to improve project performance. In some organizational cultures, there is a tendency to avoid reporting bad news until it’s too late. If you present a positive status update, it may give you a little more time to resolve problems on your own, but when a project is in trouble, project managers often need management support and attention to help turn things around. It takes courage to communicate that there are problems with the project and to ask for help. It takes courage to have a conversation with a team member who isn’t performing well or to talk with a peer who isn’t providing the necessary support. It takes courage to make the hard decisions to cancel a project to save funding or to let an employee know they no longer have a position with the project. As project managers, these situations are difficult, but dealing with them is our job.
More leadership behaviors
It’s difficult to try to categorize all the leadership behaviors a successful project manager needs to exhibit into just three areas. A commitment to customer satisfaction, a focus on quality, and continuous improvement are secondary behaviors that I’d add to the list. Successful project managers possess the technical project management skills and the leadership behaviors to deliver a project.
Provide your thoughts here or visit the TechRepublic blog site and Join the conversation!
Get IT Tips, news, and reviews delivered directly to your inbox by subscribing to TechRepublic’s free newsletters.
To learn more about the Performance & Quality Improvement Network, other topics and initiatives - subscribe to this blog, follow us on Twitter, visit our website PQI Network
April 6, 2011, 7:14 AM PDT
A lot of project management articles focus on technical aspects of the work (e.g., the latest tool, template, or technique to help manage scope, schedules, and people), but it’s just as important to focus on the social and cultural aspects of project management. Leadership, teamwork, negotiation, problem solving, and politics also have a significant impact on a project’s success.
Leadership frameworks can be taught in business schools and professional development courses, though leadership behaviors need to be learned and demonstrated. I once worked for a company that identified three specific leadership behaviors that project managers should demonstrate in addition to successful project delivery. Here’s a look at the three leadership behaviors.
Leadership behavior #1: Demonstrate a drive for results
Project management isn’t easy or filled with glory. The reality is projects are tough and can be stressful, frustrating, and have administrative challenges that can detract from the end goal. Focusing on the tasks that need to be accomplished (regardless of obstacles) and keeping the end goal in mind are easier said than done, but both concepts are critical nonetheless. Effective project managers take responsibility to achieve the results defined by the project; this means you may not be able to simply delegate tasks to others and wait for the status update. On some of my projects, I never thought I’d be the person responsible for data cleanup in legacy systems or have to conduct menial and administrative tasks in preparation for the next day’s workshop; however, sometimes completing menial tasks and focusing on the end result helps move the project forward.
Leadership behavior #2: Demand the truth
In order to make the best decisions, project managers need to know the real issue or risk affecting the project. Effective project managers need to demand the truth from their teams and then present the truth to their management and peers. Minimizing problems and hiding issues with colorful explanations doesn't help the project team or the project manager succeed. By asking team members to explain the status in basic terms without corporate rhetoric or political spin, the entire team will benefit.
Leadership behavior #3: Demonstrate courage
Projects don’t always go as planned, and it’s the project manager’s job to present the current status updates and describe any corrective actions needed to improve project performance. In some organizational cultures, there is a tendency to avoid reporting bad news until it’s too late. If you present a positive status update, it may give you a little more time to resolve problems on your own, but when a project is in trouble, project managers often need management support and attention to help turn things around. It takes courage to communicate that there are problems with the project and to ask for help. It takes courage to have a conversation with a team member who isn’t performing well or to talk with a peer who isn’t providing the necessary support. It takes courage to make the hard decisions to cancel a project to save funding or to let an employee know they no longer have a position with the project. As project managers, these situations are difficult, but dealing with them is our job.
More leadership behaviors
It’s difficult to try to categorize all the leadership behaviors a successful project manager needs to exhibit into just three areas. A commitment to customer satisfaction, a focus on quality, and continuous improvement are secondary behaviors that I’d add to the list. Successful project managers possess the technical project management skills and the leadership behaviors to deliver a project.
Provide your thoughts here or visit the TechRepublic blog site and Join the conversation!
Get IT Tips, news, and reviews delivered directly to your inbox by subscribing to TechRepublic’s free newsletters.
To learn more about the Performance & Quality Improvement Network, other topics and initiatives - subscribe to this blog, follow us on Twitter, visit our website PQI Network
March 28, 2011
Identify the Health of the Organization and Strength of Leadership - in one word
Healthy process management and problem-solving - the difference between using one of two three-letter words
Everyday and every business is faced with adversity. Sometimes these challenges are self inflected while other times they may be the result of external forces But one easy way to identify the health of a company is listening for the reactionary words used by leaders.
Yes, there are varying degrees of 'incidents' which will result in greater consequences/ramifications but this simple 'test' can be used for even the most minor setbacks. The reference to 'company leaders' is not reserved for just the members of the Executive Team (CEO, CFO, COO, etc) but to all levels of management (VPs, Sr. Officers, Managers, etc) or anyone in the company that has the responsibility for taking actions and resolving issues on a daily basis. For it is these day-to-day issues (actions and reactions) that really 'drive' a company and will ultimately decide the success or failure of the organization.
The next time an issue occurs and people are 'called' to a meeting, a conference call has been planned, or any other strategy meeting takes place and members are discussing recent issues, listen for the words WHO or HOW.
When the company (leaders) utilizes the word:
WHO = doomed for failure but How = on the right track.
Note that WHO does not need to be a single person but can also be used to identify a specific team, division, department, etc. The result is same, leaders are trying to limit the issue to the result of a failed (Person or Team) which is not a healthy approach and signifies that the company has a flawed system in place for addressing issues.
How many times does a supervisor have a 'poor' performing employee that always seems to do 'something' wrong or incorrect. The result- the supervisor fires the employee, then needs to make plans to hire a new and "better" one. On the surface, this approach is the easiest way to 'address/solve' the issue but also consumes the most resources (the additional expense and lost productivity - time between new hire starts, supervisor's time to interview, additional task for other staff to complete, cost of new-hire training, etc). Once the supervisor has the new hire up to the level as the former, all may seem well until the new employee begins making some of the same 'flaws' and eventually suffers the same fate - and is terminated. Worse yet, is when the supervisor concludes that anyone that takes the job will always perform at this same sub-standard level (because of salary limits, educational experience, etc) and compromises and begins to believe that this is "the best we can do".
Similar issues occur at the highest levels of an organization (public and private) and can be found while examining most national and state headlines. A top CEO is fired because of poor earnings or after making misguided statements during an interview. The Board replaces the executive but a couple of years later finds itself in a similar situation yet again. To top federal, state and local government agencies to members of the local county commission accused of taking part in questionable practices or abusing the power of the office and being removed. But months or years later, more members and agencies are found conducting similar wrong-doings.
We are not saying that some offenses should not result in termination but pointing out that too often the way such issues are addressed starts by identifying a WHO and that by removing or punishing is viewed as THE solution. This is the easy way out as it takes the least amount of time to offer a 'solution' that can be provided to customers, shareholders, upper management, constituents, etc. However, this approach often ONLY results in a temporary fix by removing the visible aliment in the 'WHO' but does very little to address any underlying issues that typically created the environment for such an incident to occur in the first place.... the HOW.
The correct response when issues are addressed is listening for leadership to ask 'HOW' such an incident(s) occurred...
When company leadership begins by asking HOW, they are in a better position to make meaning change that offers lasting improvements and better outcomes.
The HOW approach also promotes a Learning Organizational culture while building confidence and trust in your employees (not seeking to blame people first) and your customers (addressing the situation resulting in greater service).
The difference between mediocre & magnificent is usually a very SMALL effort... or in this case between using one or another SMALL three-letter word.
To learn more about the Performance & Quality Improvement Network, other topics and initiatives - subscribe to this blog, follow us on Twitter, visit our website PQI Network
Everyday and every business is faced with adversity. Sometimes these challenges are self inflected while other times they may be the result of external forces But one easy way to identify the health of a company is listening for the reactionary words used by leaders.
Yes, there are varying degrees of 'incidents' which will result in greater consequences/ramifications but this simple 'test' can be used for even the most minor setbacks. The reference to 'company leaders' is not reserved for just the members of the Executive Team (CEO, CFO, COO, etc) but to all levels of management (VPs, Sr. Officers, Managers, etc) or anyone in the company that has the responsibility for taking actions and resolving issues on a daily basis. For it is these day-to-day issues (actions and reactions) that really 'drive' a company and will ultimately decide the success or failure of the organization.
The next time an issue occurs and people are 'called' to a meeting, a conference call has been planned, or any other strategy meeting takes place and members are discussing recent issues, listen for the words WHO or HOW.
When the company (leaders) utilizes the word:
WHO = doomed for failure but How = on the right track.
Note that WHO does not need to be a single person but can also be used to identify a specific team, division, department, etc. The result is same, leaders are trying to limit the issue to the result of a failed (Person or Team) which is not a healthy approach and signifies that the company has a flawed system in place for addressing issues.
How many times does a supervisor have a 'poor' performing employee that always seems to do 'something' wrong or incorrect. The result- the supervisor fires the employee, then needs to make plans to hire a new and "better" one. On the surface, this approach is the easiest way to 'address/solve' the issue but also consumes the most resources (the additional expense and lost productivity - time between new hire starts, supervisor's time to interview, additional task for other staff to complete, cost of new-hire training, etc). Once the supervisor has the new hire up to the level as the former, all may seem well until the new employee begins making some of the same 'flaws' and eventually suffers the same fate - and is terminated. Worse yet, is when the supervisor concludes that anyone that takes the job will always perform at this same sub-standard level (because of salary limits, educational experience, etc) and compromises and begins to believe that this is "the best we can do".
Similar issues occur at the highest levels of an organization (public and private) and can be found while examining most national and state headlines. A top CEO is fired because of poor earnings or after making misguided statements during an interview. The Board replaces the executive but a couple of years later finds itself in a similar situation yet again. To top federal, state and local government agencies to members of the local county commission accused of taking part in questionable practices or abusing the power of the office and being removed. But months or years later, more members and agencies are found conducting similar wrong-doings.
We are not saying that some offenses should not result in termination but pointing out that too often the way such issues are addressed starts by identifying a WHO and that by removing or punishing is viewed as THE solution. This is the easy way out as it takes the least amount of time to offer a 'solution' that can be provided to customers, shareholders, upper management, constituents, etc. However, this approach often ONLY results in a temporary fix by removing the visible aliment in the 'WHO' but does very little to address any underlying issues that typically created the environment for such an incident to occur in the first place.... the HOW.
The correct response when issues are addressed is listening for leadership to ask 'HOW' such an incident(s) occurred...
- HOW questions begin to address the Circumstances surrounding the incident and not just Occurrence
- HOW begins to ask if the same result may have occurred regardless of WHO was involved
- HOW also explores what steps may be needed in order to reduce or prevent a repeat
- HOW examines necessary support mechanisms and resources - (people, training, money, structure, etc)
When company leadership begins by asking HOW, they are in a better position to make meaning change that offers lasting improvements and better outcomes.
The HOW approach also promotes a Learning Organizational culture while building confidence and trust in your employees (not seeking to blame people first) and your customers (addressing the situation resulting in greater service).
The difference between mediocre & magnificent is usually a very SMALL effort... or in this case between using one or another SMALL three-letter word.
To learn more about the Performance & Quality Improvement Network, other topics and initiatives - subscribe to this blog, follow us on Twitter, visit our website PQI Network
March 25, 2011
Collect Real Survey Data - Sometimes, Somewhat... Seriously?!
Collect Meaningful and Useful Survey Answers - NOT just Sometimes, Occasionally, or Often...
Thanks to the wide-spread availability and ease of many survey applications (we review some free applications on our Free Internet Apps site), more companies and organizations are utilizing to TRY and gauge customer satisfaction.
Maybe it is a quick survey you completed while in line, on the phone or while on a company website. Maybe you receive the survey in the mail or by email after you have been serviced or purchased a product.
Despite the accessibility of survey applications, the availability of templates to assist with creating, and the many methods of delivery, it is unfortunate that too often the data collected is "useless".
We will often discuss different aspects of developing proper Surveys but here we focus on collecting REAL answers from your respondents that can be used to make meaningful change and improvements.
But first, we want to be clear, we are not evaluating or discussing the various 'types' or design tools (such as Scaling "Likert", Response "dichotomous", Rating, etc) but more focused on improving the answers (information) you receive.
Let's look at some typical survey questions utilizing response scales:
Please select the best answer that best describes your recent visit...
1 = strongly unfavorable
2 = somewhat unfavorable
3 = undecided
4 = somewhat favorable
5 = strongly favorable
or maybe the survey asks respondents to 'select the best answer' -here is a typical question:
I am satisfied with the service I received during my last visit-
1 = strongly disagree
2 = occasionally disagree
3 = somewhat disagree
4 = undecided/unsure
5 = somewhat agree
6 = occasionally agree
7 = strongly agree
Although there are 'few' good arguments for offering respondents MANY choices and including the "safe" middle value (Neutral, Unsure, Undecided, etc) we recommend utilizing this approach as little as possible.
Instead, your answers should try to "force" respondents to select a value that is either more towards agreeing/favoring or towards disagreeing/unfavorably. After all, you're really trying to find out if they are satisfied or not, agree or disagree. If you wanted to to know "how" they felt (varying degrees) then you should ask them to write 'comments' and not simple select from a one or two-word answer.
Aside from the 'beating around the bush' approach by using words (somewhat, occasionally, often, most, many, etc), and placing the respondents in the position to subjectively decipher differences (between 'often', 'somewhat' and 'occasionally'), the business is faced with trying to assign some meaningful and valued measurement from the responses to gauge customer feedback.
The improved survey approach would look more similar to the following:
Please select the best answer that best describes your recent visit...
To learn more about the Performance & Quality Improvement Network, other topics and initiatives - subscribe to this blog, follow us on Twitter, visit our website PQI Network
Thanks to the wide-spread availability and ease of many survey applications (we review some free applications on our Free Internet Apps site), more companies and organizations are utilizing to TRY and gauge customer satisfaction.
Maybe it is a quick survey you completed while in line, on the phone or while on a company website. Maybe you receive the survey in the mail or by email after you have been serviced or purchased a product.
Despite the accessibility of survey applications, the availability of templates to assist with creating, and the many methods of delivery, it is unfortunate that too often the data collected is "useless".
We will often discuss different aspects of developing proper Surveys but here we focus on collecting REAL answers from your respondents that can be used to make meaningful change and improvements.
But first, we want to be clear, we are not evaluating or discussing the various 'types' or design tools (such as Scaling "Likert", Response "dichotomous", Rating, etc) but more focused on improving the answers (information) you receive.
Let's look at some typical survey questions utilizing response scales:
Please select the best answer that best describes your recent visit...
1 = strongly unfavorable
2 = somewhat unfavorable
3 = undecided
4 = somewhat favorable
5 = strongly favorable
or maybe the survey asks respondents to 'select the best answer' -here is a typical question:
I am satisfied with the service I received during my last visit-
1 = strongly disagree
2 = occasionally disagree
3 = somewhat disagree
4 = undecided/unsure
5 = somewhat agree
6 = occasionally agree
7 = strongly agree
Although there are 'few' good arguments for offering respondents MANY choices and including the "safe" middle value (Neutral, Unsure, Undecided, etc) we recommend utilizing this approach as little as possible.
Instead, your answers should try to "force" respondents to select a value that is either more towards agreeing/favoring or towards disagreeing/unfavorably. After all, you're really trying to find out if they are satisfied or not, agree or disagree. If you wanted to to know "how" they felt (varying degrees) then you should ask them to write 'comments' and not simple select from a one or two-word answer.
Aside from the 'beating around the bush' approach by using words (somewhat, occasionally, often, most, many, etc), and placing the respondents in the position to subjectively decipher differences (between 'often', 'somewhat' and 'occasionally'), the business is faced with trying to assign some meaningful and valued measurement from the responses to gauge customer feedback.
The improved survey approach would look more similar to the following:
Please select the best answer that best describes your recent visit...
1 = strongly unfavorable
2 = unfavorable
3 = favorable
4 = strongly favorable
or please select the best answer-
I am satisfied with the service I received during my last visit-
1 = strongly disagree
2 = disagree
3 = agree
4 = strongly agree
This improved design makes it easier for your respondents to select from and identify with clearer and less subjective choices, your questions are more to the point and the business can begin to group the collected data and evaluate the REAL customer experience.
To learn more about the Performance & Quality Improvement Network, other topics and initiatives - subscribe to this blog, follow us on Twitter, visit our website PQI Network
Subscribe to:
Posts (Atom)