11 Commandments and 10 Reasons

Two good lists:

11 Commandments for an Enthusiastic Team

1. Help each other be right....not wrong.
2. Look for reasons to make new ideas work - not for reasons they won't.
3. If in doubt, check it out. Don't make negative assumptions about each other.
4. Help each other win and take pride in each others victories.
5. Speak positively about each other and your organization at every opportunity.
6. Maintain a positive mental attitude - no matter what the circumstances.
7. Act with initiative and courage as if it all depends on you.
8. Do everything with ENTHUSIASM...it's contagious.
9. Whatever you want ... give it away.
10. Don't lose faith and never give up.
11. HAVE FUN!!

and

The Top 10 Reasons Projects Fail

1. Inadequately trained and/or inexperienced project managers
2. Failure to set and manage expectations
3. Poor leadership at any and all levels
4. Failure to adequately identify, document and track requirements
5. Poor plans and planning processes
6. Poor effort estimation
7. Cultural and ethical misalignment
8. Misalignment between the project team and the business or other organization it serves
9. Inadequate or misused methods
10. Inadequate communication, including progress tracking and reporting

For more information, check out Ian Percy's site (11 Commandments) and Frank Winter's series (login required) on GanntHead.com.

Technical Architect

Here's a job description for Technical Architect that I recently submitted for a position that I believe is a need of my current client. The description is at the bottom of the post. Along the way, I found some good resources on understanding this new role of Architect (Technical, Systems, Application, Data, Web, Software, Solutions, Enterprise, Information, or any specific platform such as Java or .Net).

One good source was Seven Habits of Highly Successful Enteprise Architects. There is also some brief descriptions and a wealth of links on Worldwide Institute of Software Architects (WWISA) New Zealand Chapter's site. Dana Bredemeyer has also published some articles defining the role of Architect, and has a resources site for for Software Architects.

After reviewing those sources and reviewing some job descriptions on dice.com, I came up with the following:

Job Title: Technical Architect

Duties and Responsibilities
Assists and guides in effort to move from reactionary to proactive (trouble-shooting environment to problem prevention).
Enable tighter business/IT alignment, better-quality decisions, and the successful implementation of an enterprise architecture
Assists in business strategy and process engineering
Responsible for solution options, trade-offs, design and implementation. Responsible for application integration. Responsible for review and implementation of third party solutions or tools. Responsible for standards definition and review.

Qualifications, Skills and Abilities
Personal Traits / Behavioral Competencies
1. Strong leadership skills
2. Excellent written and oral communications skills
3. Proactive – Identifies problem areas and opportunities and makes recommendations
4. Provides thought leadership, thinks strategically
5. Exceptional interpersonal skills
a. Builds rapport & trust
b. Excellent team player and team builder
c. Strong facilitation and negotiation skills
d. Persuades & communicates effectively
e. Ability to moderate and build consensus
f. Ability to articulate and sell a vision
g. Ability to mentor and coach
6. Delivers practical results – Quantifies return on investment
7. Is agnostic toward technology vendor and product choices; more interested in results than in personal choices
8. High tolerance for ambiguity. Resilient
9. Entrepreneurial and creative
10. Practical and pragmatic
11. Empathetic and approachable
12. Committed, dedicated, passionate

Skills and Credentials
1. Bachelor’s degree in computer science, computer engineering, electrical engineering, systems analysis, or a related study, or equivalent experience.
2. Three to four years of experience in at least two IT disciplines OR three to four years of experience in business analysis or business strategic planning.
3. Exposure to multiple, diverse technical configurations, technologies, and processing environments.
4. Excellent analytical and technical skills.
5. Excellent planning and organizational skills.
6. Knowledge of all components of a technical architecture.
7. Knowledge of business re-engineering principles and processes.
8. Understands the business, business drivers, and business strategy
9. Demonstrates technical prowess
10. Strong understanding of network architecture.
11. Strong understanding of client/server and object-oriented analysis and design.
12. Ability to understand the long-term (“big picture”) and short-term perspectives
13. Ability to translate business needs into technical architecture requirements.
14. Ability to apply multiple technical solutions to business problems.
15. Ability to quickly comprehend the functions and capabilities of new technologies
16. Good understanding of technology trends. Technical vision
17. Good interviewing skills
18. Understands system analysis and synthesis, modeling, conceptualization
19. Trade-off analysis. Technical reviews and assessments. Technology selection
20. Project/transition planning. Able to manage and coordinate key project elements

Other Abilities
1. Researching: must become adept at understanding issues and finding answers quickly and creatively.
2. Analyzing: must be able to formulate questions used in business conversations to elicit facts or statements from them, and be willing to listen to what these individuals have to say.
3. Engineering: must be able to apply principles of logic, science, and mathematics to the understanding of systems and processes so the latter can be improved.
4. Communicating: must be able to expound on an important subject to inform and instruct an audience, convincing members to take further action. This entails persuading, marketing, and selling.
5. Arbitrating: must be able to reconcile differences to achieve a common objective and find appropriate solutions.
6. Teaching & Mentoring: must be able and willing to transfer knowledge to others, if necessary, identifying their weaknesses and helping in their correction.
7. Organizing: must be able to put things together in an orderly, functioning, structured whole. This entails handling multiple things at the same time effectively.

The Q12 - The 12 Questions That Matter

Gallup has distilled 12 core issues (called the "Q12" in Gallup-speak) that represent a simple barometer of the strength of any work unit. You can read the full article "Marcus Buckingham Thinks Your Boss Has an Attitude Problem" here.

If you want to build the most powerful company possible, then your first job is to help every person generate compelling answers to 12 simple questions about the day-to-day realities of his or her job. These are the factors, argue Marcus Buckingham and his colleagues at the Gallup Organization, that determine whether people are engaged, not engaged, or actively disengaged at work.

Here are the 12 Questions That Matter:

1. Do I know what is expected of me at work?
2. Do I have the materials and equipment that I need in order to do my work right?
3. At work, do I have the opportunity to do what I do best every day?
4. In the past seven days, have I received recognition or praise for doing good work?
5. Does my supervisor, or someone at work, seem to care about me as a person?
6. Is there someone at work who encourages my development?
7. At work, do my opinions seem to count?
8. Does the mission or purpose of my company make me feel that my job is important?
9. Are my coworkers committed to doing quality work?
10. Do I have a best friend at work?
11. In the past six months, has someone at work talked to me about my progress?
12. This past year, have I had opportunities at work to learn and grow?

The Lost Meeting of IT Process Gaps

The other day I overheard a group of three IT workers (DBA's and Database Developers) candidly discussing their views of IT process problems that related to their jobs. They talked about responsibilities, gaps or shortcomings in roles and responsibilities, and the interdependencies between their group and the other groups of front-end developers, Quality Assurance and the Business Analysts. This was not a gripe session, nor these people complains. They are smart, hard workers and have good attitudes. They were discussing items such as why do we allow specs to come in late, rush critical process like promotion of code to production, continue to repeat mistakes, miss obvious gaps in roles and responsibilities. They cared about their work, wanted to be productive, and were thoughtful about how things are and how things could be.

I thought that their views would be valuable to management, but my guess is that management will never hear any of it. It feels as it as soon as there is an official meeting to discuss process problems, no one shares the views openly and honestly. For the most part, people don't want to appear mean, crititical or attacking, or hurt important interdepartment relationships, and certainly they do not want jeopardize their career future by commenting on management itself.

So how do we get insight from those closest to IT processes (and problems)? If meetings don't do it, perhaps lunch one-on-one's would. After 5 - 10 lunch meetings, a more clear and well-rounded view of issues might come into view. If any specific issues came up that needed to be dealt with, it would be more difficult for the group to feel that any one person was a whistle-blower. Additionally, issues with a manager might be approachable because the manager is not in front of a group and potentially embarrassed.

At the very least, one might get to know their workers better, and the workers would feel valued and appreciated for the time.

...You Need to Know, Pt. 3 - Leadership

For the past two posts, I have been reviewing Marcus Buckingham talk "One Thing You Need to Know." This is the final post on the session.

The job as a leader, according to Buckingham, is to rally people to a better future. One trait of leaders is that they are deeply, deeply optimistic. They are not naive, nor unaware of the dangers and difficulties. They have egos to lead. Some would say a leader should have strong ethics and integrity. We all should have that. But leaders have self-confidence and assurance above what most people, including managers, have. Leaders want to steer the boat, and believe in their hearts that they should be the one to do it.

Leaders find what is universal about their people and capitalize on it. One universal trait among people is fear of the unknown. And leaders traffic there.

The disciplines of leadership are:
1. Reflection, typically on excellence. Many people fail because they fail to understand what success means.
2. Picking the right heroes.
3. Practice - the words, stories to answer the universal fears and concerns of their people.
4. Clarity. Who do we serve? What is our core strength? What is our core score/metric? What actions can we take today? Why will we win? What is our competitive advantage?

Getting back to engaging workers, outstanding management and leadership engages people, not leaving 20% actively disengaged, wasted potential, like, as Buckingham said, "sundials in the shade."

More on Gallup's Q12 that lead to First, Break All the Rules here...
A summary of the strengths movement is here and related materials here.

...You Need to Know, Pt. 2 - Management

In my previous post I review the first part of Markus Buckingham's session, covering the value of engaging employees. In this post, I'll review how management and leadership does this through management (Leadership will be Part 3).

Management's chief responsibility, says Buckingham, is to take their talent (people) and turn it into performance. They are a catalyst, and genuinely believe in their people. Great managers find what is unique about each of the workers, and capitalize on it. Buckingham compared it to the difference between chess and checkers. Good chess players understand how to take advantage of the different moves the pieces can make. The managers do this by:
1. Knowing a person's strengths and weaknesses, and managing around the weaknesses.
2. Knowing a person's triggers (what motivates them). This could be what work week schedule works best for them, more face-time with their boss, more independence, having an audience, being praised in front of peers or praise from the customer, awards, certificates.
3. Knowing a person's optimal learning style:
a. Analyzer - leave them alone with the directions. They hate mistakes. Don't ever throw them into a situation where they must perform right from the start.
b. Doer - Throw 'em in the ring and let them have it. They learn doing it. Give them the task, state the expected result, and get out of the way. For them, work doesn't have meaning unless it is for a real situation (meeting, presentation, production).
c. Watcher - Learns by imitation, watching. Have them rides shotgun with your best employee.

How does a manager learn what motivates their employee and what the employee's optimal learning style is? Pay attention. Ask them questions such as:
1. What was your best day at work? Why? How can you repeat it?
2. What was your worst day at work? Why? How could you avoid it?
3. What was your best manager relationship?
4. What was the best recognition you ever had?
5. When in your career did you learn the most? Why?

More on my next post...

Marcus Buckingham - One Thing You Need to Know

It's been a week now since I heard Marcus Buckingham's session "Discovering your Leadership Strength." Marcus Buckingham is the coauthor of First, Break All the Rules, as well as other articles and books.

Marcus' talk was focused on management and leadership and the impact of engaging employees has on company performance. Gallup polls had asked employees around the world if they felt they had the tools and skills to do their job (competent), knew what was expected (focused), and believed in what the company's mission (confident/spirited). Gallup then categorized workers as being Engaged, Neutral, or Actively Disengaged, depending on how the questions were answered. Engaged workers are in their "sweet spot", but account for only 29% of the workforce in the US. Of the rest, 55% were neutral and 16% were actively disengaged (Marcus jokingly said "bitter"). A German paper had reported on this information, and translated actively disengaged as "quitting in the brain."

The difference of having engaged or actively disengaged is reflected in one nationwide chain that had employee turnover of 10-15% in one store and over 200% in another store in the same area. Same company, same area, same company policies, same job descriptions, same benefits. Another company measured part of its success via safety. One site had 0% of employee accidents for the year, while another had 25% in only two months. Once again, same company, same safety policies, but different local engaged or disengaged workers.

Per Marcus, a company creates:

• Competent people by how the company picks and trades them
• focused people based on how the manage them and
• Spirited workers through how the company leads.

I'll review how management and leadership does these three things on my next post.

Tim Sanders Session at The Leadership Summit

I attended several sessions of The Leadership Summit last week.

Tim Sanders , Leadership Coach for Yahoo!, shared that we often don't have faith in our people or ourselves. There are those that have an attitude of 'scarcity', driven by fear of competition and filled with a sense of lack, what they don't have. It's the difference between social networking for other's benefit and networking for personal gain (which he said is actually prospecting or brokering). He gave a good word picture by saying "It's the difference between being a gardener and a butcher."

Tim said that at Yahoo!, if you are driven by scarcity (nay-sayer, doom and gloom), they will literally stamp a piece of paper with "Chicken Little" and stick it to your back, to be left there all day.

Tim made me think how often I look to the negative side of a situation. In software development, we need to look at the possible concequences, but really only as risk analysis. Even then, the downside should perhaps only be considered, noted, and then everyone should move forward on the project focussing on the upside. This doesn't mean be unrealistic, niave, or wear rose-colored glasses, it only means that we decide to concentrate our energy on the possible positive outcomes, encourage others, and be a contributor to the solution. And an IT project, we could all agree, is much more than flowcharts and code.