Review firm which conducts a full investigation into background and activities of prospective employees
http://www.creativeservices.com/

According to the Association of Support Professionals the cost for TotalCost of Owning a Solution (TCOS)

• Phone Support averages about $36.00 TCOS per instance
• Email Support averages about $25.00 TCOS per instance
• Self Service is averaging about $7.00 TCOS at cost

Self service reduces your support by 5X !

“Mastering Change Management:
Why Organizational Change Fails”

“There is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success than to take the lead in the introduction of a new order of things.”
Jean-Jacques Rousseau

Have you experienced a failed change lately? Been a part of a team or an organization that attempted something different…and failed?

We’ve all seen attempts at change bomb. What happens to scuttle well-intentioned effort? The following are some of the most common reasons I’ve identified why organizational change fails. You can use the list for diagnostic purposes, or to prevent mistakes in future attempts at change.

1. Misstarts

A misstart occurs when a change is ill-advised, hastily implemented or attempted without sufficient commitment. This is a leadership credibility killer.

2. Making change an option

When leadership commits to a change, the message must be that the change is not an option. But the message that often comes across is “We’d like you to change, we’re asking you to change, we implore you to change, please change…” Whenever people have the option not to change, they won’t.  

3. A focus only on process

Leaders can get so caught up on planning and managing the process that they don’t notice that no tangible results are being achieved. The activity becomes more important than the results.

4. A focus only on results

This stems from a belief that the end justifies any means. Organizations tend to fail miserably in this regard: they downplay or ignore the human pain of change. It is this insensitivity to people’s feelings that not only prevents the change but destroys morale and loyalty in the process.

5. Not involving those expected to implement the change

A great deal of resentment is aroused when management announces a change and then mandates the specifics of implementation. Employees need to be involved in two ways. First, their input and suggestions should be solicited when planning the change. Secondly, after a change has been committed to, they should be involved in determining the means. Leadership needs to communicate, “Here’s what must happen. How do you think it can best be done?
a good primer on Change Management

One of the most intensive certifications available is the PMP® (Project Management Professional) certification. Offered by PMI (Project Management Institute), the PMP® demonstrates advanced knowledge of and experience with Project Management concepts. When it comes to finding internet resources and practice exams, it is also one of the most difficult and obscure certifications. As a result of several interviews requesting this certification, and quite a bit of research here is my breakdown on the PMP Cert:

Most training for the PMP® certification is both intensive and costly, but the PMP® is generally considered a good investment. According to my 2002 certification salary survey, individuals with a PMI cert averaged $90,000 per year. Fortunately, good practice questions are just beginning to appear on popular training sites so you can get an idea of where your strengths and weaknesses lay before taking the exam.

This is the problem in and of itself is that as I just said it mostly covers just that — best practices. It is a never ending always evolving discipline so I have only continued development and let my experience earn me a “real world certification” not just what a dated curriculum instructs… I know it is a matter of principle that you as a professional can follow a disciplined course and get fundamentals that others can measure too so all are on the same page… HR people it seems screen for this as a crutch I feel all too often. But as a active professional, I never have time nor xtra energy to exert in taking schooled courses… Thats why I buy e-books like McGraw-Hill PMP Project Management Professional Study Guide so I am on top of the game. Another book to get is the Project Management Institute, A Guide to the Project Management Body of Knowledge (simply referred to as the PMBOK) And when the time comes, and the account requires the certification; I will challenge the HR depts. to cover my expenses for the PMP Exam as part of my coming aboard. And if this isnt good enough then those companies arent really looking for someone as good as YOU or ME. . . They are obviously seeking a troll.

As time allows I will publish the Axioms I digest from the e-book for your benefit and reading pleasure !

1. First off the book is more concerned about the expensive Exam than the damn principles you are supposed to learn and digest, (isnt that what the importance is not just passing a stupid test) thats why I call my programming & development a Multimedia Practice because just like a doctor, though they study their tails off until they get into surgery they dont have enough experience even from their residency to pass any sort of exam!
2. project is defined as a temporary endeavor undertaken to create a unique product or service
   Operations are the day-to-day work that goes on in the organization
   ergo:
   Projects, on the other hand, are short-term endeavors that fall outside of the normal day-to-day operations an organization offers…
3. Often projects are confused with general business duties: marketing, sales, manufacturing, and so on. The tell-tale sign of a project is that is has an end date and that it’s unique from other activities within the organization…
4. The end results of projects can result in operations. That’s why I have always A)executed a project then B) provided Ongoing Service Agreements (OSA) to support all ongoing business operations thereafter…
5. Projects vs. Operations — just covered the cert’s stupid need to clearify… but for those who dont routinely do this, it IS GOOD it is object oriented nomenclature…
6. Progressive Elaboration — All projects begin as a concept to create a new product or service
   Progressive elaboration is the incremental design and refinement of the initial concept
   toward the project plan.
   Complete understanding of the needs-and the ability to fulfill those needs-comes from progressive elaboration
   This is why I have a Project Vision Memorandum (PVM) and it evolves into harvesting a
   Marketing Requirements Document (MRD) and/or a Work Breakdown Structure (WBS)
7. Defining Project Management – Project management is the supervision and control of the work required to complete the project vision.
   > Project Integration Management
   This knowledge area focuses on project plan develop and execution.
   > Project Scope Management
   This knowledge area deals with the planning, creation, protection, and fulfillment of the project scope.
   > Project Time Management
   Time management is crucial to project success. This knowledge area covers activities, their characteristics, and how they fit into the project schedule.
   > Project Cost Management
   Cost is always a constraint in project management. This knowledge area is concerned with the planning, estimating, budgeting, and control of costs.
   > Project Quality Management
   This knowledge area centers on quality planning, assurance, and control.
   > Project Human Resource Management
   This knowledge area focuses on organizational planning, staff acquisition, and team development.
   > Project Communications Management
   The majority of a project manager’s time is spent communicating. This knowledge area details how communications can improve.
   > Project Risk Management
   Every project has risks. This knowledge area focuses on risk planning, analysis, monitoring, and control.
   > Project Procurement Management
   This knowledge area involves planning, solicitation, contract administration, and contract closeout.
8. Defining the Project Life Cycle – Each phase within the life of the project created a deliverable.
   
9. Milestones – Often, the deliverable of each phase is called a milestone. The milestone is a significant point in the schedule that allows the stakeholders to see how far the project has progressed-and how far the project
   has to go to reach completion.
10. Defining the 5 Project Management Process Project Management, explores five major processes
    

1. Initiating
   This process launches the project, or phase. The needs of the organization are identified and alternative solutions are researched. The power to launch the project or phase is given through a project charter, and when initiating the project, the wonderful project manager is selected.
2. Planning
   Can you guess what this process is all about? The planning process requires the project manager and the project team to develop the various core and subsidiary management plans necessary for project completion. This process is one of the most important pieces of project management.
3. Executing
   This process allows the project team and vendors to move toward completing the work outlined in the Planning process. The project team moves forward with completing the project work.
4. Controlling
   The project manager must control the work the project team and the vendors are completing. The project manager checks that the deliverables of the phases are in alignment with the project scope, defends the scope from changes, and confirms the expected level of quality of the work being performed. This process also requires the project manager to confirm that the cost and schedule are in sync with what was planned. Finally, the project team will inform
   the project manager of their progress, who will, in turn, report on the project’s progress to the project sponsor, to management, and perhaps even to key stakeholders in the organization.
5. Closing
   Ah, the best process of them all. The closing process, sometimes called the project postmortem, involves closing out the project accounts, completing final acceptance of the project deliverables, filing the necessary paperwork, and assigning the project team to new projects.
6. Oh yeah, Ill ADD a 6th lol celebrating !

11. project manager will encounter three constraints:
Project Scope, Schedule, Budgeted Cost

12.Management by Projects
An organization that uses projects to move the company forward is using the Management by Projects approach. These project-centric entities could manage any level of their work as a project. These organizations, however, apply general business skills to each project to determine their value, efficiency, and, ultimately, their return on investment. As you can imagine, some projects are more valuable, more efficient, or more profitable than others.

13. Here’s where it becomes spaghetti:
There are knowledge areas which are based on the five IPECC Processes above:
Project Integration Management
Project Scope Management
Project Cost Management
Project Quality Management
Project Human Resource Management
Project Communications Management
Project Risk Management
Project Procurement Management
There is a grid/matrix that threads dependencies between all of these to study on pg38 of the PMBOK.

14.  Adapting Management Expertise
Let’s take a quick look at some of the attributes of a successful project manager
Communications
Budget Management
Project Organization
Negotiation Skills
Team Leadership

15. I just learned my first thig in the book! I can now define that I am affluent at “Adapting Application Areas” of expertise. meaning that I can use alot of experiences in many disciplines to add greater added value to the PM role and responsibilites of any project…

16.  Program Management vs. Subproject Implementation

17.  Project Portfolio Management

and there’s my overview… I bet I’d pass the PMP with flying colors and so could YOU !!!
any questions then write me I LOVE talking about this stuff over a wine and a cigar !

two great links I scrambled to find I like alot about
Information Arcitects and the critical importance of thier responsibilities…

Big Architect / Little Architect :: Team synergy connections = Ev01v3

The IA Process

Don’t underestimate the politics that occur in a small- or medium-sized company.While politics also exist in large corporations, the interactions in a smaller company are stronger and more like those of a family–with deeper relationships and barriers. If the politics are too strong, the project may be destined for failure! and no matter what you try, you will nevermake someone change… But asking more candid questions up front to better ascertain any political obstacles and adequately address those concerns first will help you plan for anything else.After doing this, professionally and factually express the risk and project viability up front, not just the details about the tasks you’re about to throw yourself into. I have come to realize I tend to bury myself in debugging things asked of fellow employees of the Team and preparation of info to assist members of my Team with thier tasks more than I worried about the administration of presenting to the upline to a high degree powerpoint on what I was achieving for them. I have been doing a Word document, but I do not feel it is probably enough especially if that individual is not extremely tech savvy themselves.. You should not forget or short-change this item. This also can be used as good documentation of a successful contract - done as you do it along the road of production.

Target Audience
Concept
Objective
Deliverables Index
Development Considerations
Featured Elements
Timeline

Thank you for the opportunity to contribute to ___________ . I have enjoyed many challenges and rewards during my contract… Specifically, I have been involved in the following activities ____________________ which help prove that I am moving the “Business/Sales needle” positively and show the connection between the work we do and the revenue ___________  produces : 

Define to others when corporate values must take precedence over geeky values

Not being interested in business, many developers tend to ignore necessities like deadlines. Many become skilled at dodging them even if by thier subconscious. The problem isn’t that most developers can’t be trusted to work responsibly by themselves, so much as the fact that they can be almost guaranteed to tinker as much as the schedule allows. In such cases, for all that successful management of super-geeks means understanding their culture, it also means recognizing when moving to achieve corporate goals are more important. At times, understanding needs to take second place to necessity, even at the cost of resentment toward the PM. Skilled project managers minimize conflicts with their staff, but they also recognize that some conflicts are unavoidable. Like I told my wife jokingly this evening at dinner it’s lke an iron fist in a pink fuzzy glove…

Culmination of tonights rant

Managing programmers — especially LAMP/FOSS ones — is an extreme version of the balancing act that any manager must do. On the one hand, managers need to understand the culture of their departments and how to work within them. Being new to my current Team it is hard to establish respect in the identification of the leadership role over ‘veterans of the Matix’. On the other, I am maintaining a liasion role as an outreach and intermediary between that culture and the rest of the company which requires answers from us. Combining these goals means adjusting my concept of management for the department. I explained that to my upline this afternoon. Sometimes, it means interpreting programmers to non-programmers in CS, or shielding programmers from the misunderstanding of executives in order to achieve corporate goals. These are hard fought battles that the programmers may never catch wind of, but a good PM must wage these battle fronts for the betterment and sustainability of thier department especially during the closure of a deadline. At other times, it means awakening programmers to the larger goals of the company. My point is it’s all a precarious balance act, but knowing what to expect as you go into a new position (3 weeks now) can leave you with more time to handle the challenges that arise without being distracted by cleaning up your mistakes or engendering a lack of cooperation from your team.

 I got Poison Ivy this last weekend cutting grass in areas of my mother-in-law’s house that hadn’t been touched for three summers! LOL so in my turmoil and peering through one and a half eyes ( since my right eye is almost swollen shut) I spent tonight studying thru 392 pages of pure PM goodies !

I have listed the most important take-aways from studying and reading The Art of Project Management by Scott Berkun of Microsoft. I list these points in hopes to help others in thier PM adventures…

When scheduling became something I was responsible for, I realized the unspoken truth about schedules. .  .

They are not gifts from the future. There is no magic formula or science for creating perfect schedules. Despite my youthful perceptions, scheduling is not an isolated task: it always represents and encompasses many different aspects of what the project is now and will be later. Schedules are simply a kind of prediction. No matter how precisely they are drafted or how convincing they appear, they are just a summation of lots of little estimations, each one unavoidably prone to different kinds of unforeseeable oversights and problems. Good schedules come only from a leader or a team that relentlessly pursues and achieves good judgment in many different aspects of software development. You can’t be an expert in one narrow part of the making of things and ever expect to schedule well.

By the simplest definition, good work estimates have a high probability of being accurate, and bad work estimates have a low probability. I don’t expect to win any awards for these definitions, but they do imply at least one useful thing: it’s the judgment of team leaders that defines the bar for a given project. It requires an active process of reviewing estimates and pushing, leading, and nudging others to get them to the level they need to be. I think it’s smart to openly involve the test/QA team in the estimation process, letting them participate in the design discussions and ask questions or offer commentary. At a minimum, this will help them with their own estimates for testing work, which may not correlate to programming work estimates. Often, QA has the best insight into design oversights and potential failure cases that others will overlook.

One thing that makes scheduling difficult is that few people enjoy estimating complex things that they will be held accountable for. It’s always fun to brag and make bets about our skills (”This book/movie/web site stinks: I could make one soooo much better”), but when we’re pressed to step up and deliversigning our names on a contract detailing our responsibilitythings change. We know that it’s entirely possible that whatever we commit to doing today might be impossible or undesirable to do when that time comes. It just might turn out to be more difficult than we thought. Programmers are just like everyone else and have good reasons to have estimation anxiety. By saying that something can be done in a certain amount of time, they risk being very wrong.

In my experience, even programmers who understand the estimation process and believe in it, don’t like to do it. Part of it is the mismatch of imagination (”How will this work, given the very limited information I have?”) with temporal precision (”Tell me exactly how many hours this will take to do.”). But sympathy here should be limited: everyone who works in engineering and construction has the same kind of challenge, whether it’s building skyscrapers, remodeling a kitchen, or launching spacecraft to land on other planets. From reading about how these folks estimate things, it doesn’t seem that their challenges or techniques are fundamentally different from what web developers and software engineers face. The primary difference is in how much time they are given to generate estimates and how disciplined they are in the use of that time

A handy technique I found was that whenever a programmer balked at giving an estimate, I’d ask, “What questions can I answer that would make you more confident about giving an estimate?” By getting him to be specific, I gave him the opportunity to confront the fear or frustration he might feel, which allowed me to help solve his problem. Of course, I’d have to help find answers to his questions, and possibly debate the issues I felt it was his job to investigate, but at least we’d be talking about getting better estimates

Planning for the software or solution :

Marketing requirements document (MRD).

Vision/scope document

Specifications document

Work breakdown structure (WBS)

In Tom Peters and Nancy Austin’s classic, A Passion for Excellence (Warner Business Books, 1985), a sort of behavior to build informal relationships/friendships with developers is called management by walking around (MBWA). It is a good form of commnication. It also breeds a good work attitude. It’s described as a central quality in the successful managers they observed (an entire chapter in their book is dedicated to it). But it’s not easy to do well. They recommend explicitly picking a small number of people, at different levels and roles in the team, and investing time in building this kind of informal relationship with them

Because I couldn’t find a published history of annoyance, I’m relying on my own observations in summarizing why people get annoyed. I have a fair amount of experience in this area: I’ve been annoyed many times, have witnessed other people in a state of annoyance, and have been known to, on occasion, annoy others. While there are certainly other causes of annoyance beyond the ones in the following list, these are the most common and important ones I know of.

For the full effect in understanding these examples, they are described in the first person (it may help to think of a specific person you have experience working with, who you respect, when reading through these).

• Assume I’m an idiot. If I have been hired to do X, which I am capable of doing, anytime someone treats me as if I cannot do Xor need a 20-step procedure, rulebook form, template, daily evaluation, committee, or other process to enable me to do XI will be justifiably annoyed. Part of my job should be to help define my work in a way that satisfies whatever objectives management decrees. But until I fail and prove incompetence, I should be treated as competent. I should be free to define, within reason, the best way to get my work done.

• Don’t trust me. If, on a daily basis, I am expected to check in, double check, triple check, and report on decisions that are well within the range of my responsibilities, I will be annoyed. If I must confirm everything, what authority do I really have? Why does everything need to be documented and recorded if I’m doing a good job? Even if I’m not initially trustworthy for some reason, it should be management’s job to provide a fair path for me to earn trust and to help me progress on that path.

• Waste my time. If the way the team functions forces me to repeat (tedious) tasks many times, or go far out of my way to protect against contingencies and management paranoias that are comically unlikely and insignificant, I will be annoyed. This includes flip-flopping on important decisions or being grossly inconsistent in messaging or behavior without making any attempt to explain it (or at least apologize for it), even when asked.

• Manage me without respect. If I am ever sent on a wild goose chase, given assignments that have no basis in reality, or set up to fail and take the blame for things beyond my scope of responsibility, I will be annoyed. Someone should be looking out for me and making sure my efforts align with the project’s, guiding me toward success. Therefore, my requests for assistance should be taken seriously and not be excessively delayed or ignored.

• Make me listen to or read stupid things. Anytime I am required to listen to someone else or read something another person has written that has no meaningful bearing on the work we are doing, I will be annoyed. We have a triage bar for bug quality: why not one for stupidity? Just because someone calls a meeting, writes a paper, or sends an email doesn’t mean it’s worth my time. The more secondary or tertiary things I’m asked (or forced) to do, the less productive and happy I am.

Most of these reasons for annoyance explain why many people loathe the idea of work processes. They fear that any attempt to systematize their work can result only in bureaucracy or other forms of suffering. I think the fear is unfounded. People design processes, just like everything else, and if the designer is smart and has the right goals in mind, the processes can benefit everyone. Process can help people instead of restricting and annoying them.

As remedial a subject as it seems, email is still the most annoying system people on projects deal with. Simply as a result of the volume of email we receive, it’s easy to feel pressure to read and respond to new messages as quickly as possible, often sacrificing good reading and writing skills. Most of us, most of the time, just don’t read or write email very well. What’s ironic is that the speed and convenience of email are squandered when we can’t understand what the hell the other person is trying to say, or we can’t get her to understand what we’re trying to tell them.

And perhaps of most importance to project management: email is a primary means of communication for leaders and managers. In both creating new mail and responding to mail sent by others, a leader influences and controls the flow of information through a project. If a leader has clear thoughts and asks solid questions, she encourages others to do the same. One response to a large discussion with dozens of people can send a wave of clarity through the organization. But, the leader hurts the team’s ability to communicate well if she expresses fuzzy thoughts and makes obscure or obfuscated points.

One major challenge is that few people admit that they send bad email. (Their inability to recognize bad email is part of why they’re bad at writing it.) For example, take the following test: using your own subjective judgment, what percentage of email that you receive from people within your own organization is high quality? Average quality? Totally useless? Now ask yourself what percentage of the email you send fits into each of these categories. As an experiment, I once asked a small group of PMs, testers, and programmers this very question. By a factor of almost 2 to 1, everyone claimed that other people wrote crappier mail than they did. Because they all worked together, this anecdotal data implied that everyone thinks the problem is email generated by others, not themselves. I don’t have harder data to support this claim, but it rings true. Somehow, when there’s a communication failure, on average people tend to blame the other guy (for copious evidence, see any history of international politics in Western civilization).

Smart managers value good email. Managers read so much poorly written email every day, and if they don’t take the time to reward those who communicate well, they’re unlikely to see more people do it. Little side emails take about 15 seconds to send, and as my story indicates, may mean more to others in your organization than you think.

But praising others is easier than taking responsibility for your own bad email habits. As I mentioned previously, I’m convinced that most people think they write better email than others think they do (and the more senior you are, the harder it might be to get honest feedback about your email etiquette). Because leaders and managers send more email than others, it’s critical to sort out what bad habits you have and invest energy in curbing them. Here is some project management-style advice on what good email looks like and what some of the common bad habits are.

• Be concise, be simple, and be direct. Pascal, the mathematician for whom the language is named, once wrote “If I had more time, I’d write a shorter letter.” Language, like code, can be optimized, although the goals are different. Instead of optimizing for logical efficiency, you want to optimize for communication efficiency. Unlike code, a grammatically and logically correct three-word message is useless if the recipient can’t figure out what the hell it means. Consider who is reading the email and how you would explain or ask whatever it is you need to say if you were talking with him face to face. What details would be needed? Omitted? What concepts can you assume he knows? What metaphors can you use? For important email, step away from it for a few minutes and then reread it, with these questions in mind, before you send it. Or for important mail, or mail going to a large number of people, have one of the people on your team skim it over and give you feedback.

• Offer an action and a deadline. The best kind of email has a specific intention or request that is clearly stated, and, if appropriate, is tied to a reasonable deadline. It should be easy for people reading the email to understand why they are receiving it, how they are impacted by the action, and what they need to do (before the deadline). Assuming you enforce the deadline (”Requests must be in to me by Friday”), you set yourself up for people to be attentive to future actions you communicate through email, which puts you in a position of power.

• Prioritize. Is it really necessary to send that email? The more emails you send, the more work others will have to do to prioritize your requests. How many of the things you’re mentioning are important? If you have 10 issues to discuss, break them into two groups and focus on the most important group. Consider if some things can be better handled on the phone, in the next team meeting, or by going door-to-door. If you don’t prioritize, expect the recipients to prioritize for youin a way that serves their interests, not yours.

• Don’t assume people read anything (especially if it’s important to you). It’s arrogant to assume that because you sent it, someone has read it. People get tons of email every day, much of it from people just as important as you are. The more important the issue is to you, the more energy you have to expend to make sure people actually see it and are actively doing something about it. The more trust you’ve built with the people on your team, the more assumptions you can make about how people will respond to things you send.

• Avoid giving a play-by-play. It’s rare that anyone needs to know the sequence of events that led to something happening. Avoid writing emails that focus on the contributing actions by different players: “When Sally first designed our build process, she was interested in…” or narrative-driven prose like “The meeting started off fine, with Bob and Steve talking through their slides with great passion and conviction. That is, until….” Instead, focus on impact: what happened, how this changes the world, and what we’re going to do about it. If you’re compelled to include background details, list them below the critical points. The same goes for references to slide decks, web sites, papers, etc. Make it possible for anyone to skim the first two lines and know immediately if it’s important enough to them to read any further.

• Sequester FYIs. I’ve been on teams that persisted in forwarding tons of semi-interesting-but-not-directly-relevant-to-anything email. Some people call these FYIs, or for your information emails. Curiosity and industry awareness are fine habits, but don’t let them dominate communication forums used for more tangible work. Set up an email alias or discussion group for “industry trends” or “tech watch,” where your team can post the cool things they find. If your email client supports it, ask everyone to set these kinds of emails to low priority, or add “FYI:” to the front of the subject line. Make this stuff easy for people to filter out.

• The telephone is your friend. If ever you don’t understand something in an important email you’ve received, don’t respond with an elaborate five-part question. See if you can reach the sender of the email on the phone. Interactive communication is always better at resolving confusion and conflict than email. A 30-second phone conversation is often equivalent to a long series of time-consuming email exchanges. If you do get the sender on the phone and resolve the issue, you can then share your clarified understanding in an email sent to everyone: odds are good that if you were confused, so were others. Telephones (or a walk down the hallway) are the great expediters of group email communication.

An example of good email

This email does not tell any stories or try to justify anything: it’s all action. It’s short, clear, and to the point. Instead of talking about proposals, it actually offers one. While it has the flavor of an ultimatum, it serves the purposes of creating escape velocity for the proposal, helping to push it out the door.

From: J Aaron

To: _blank_ internet development team

Subject: New check-in process

The final proposal for the new check-in process is complete and is up on the web site: http://yourURL.

Because this has been a contentious issue, I’ve discussed this proposal one-on-one with much of the team and incorporated everyone’s feedback. If this didn’t include you and you have strong opinions, please send me mail ASAP.

But be warned: this is the second public notice about these upcoming changes. The opportunity for making changes is currently small and is getting smaller by the day. Please act now or prepare to hold your peace.

Friday at 5:00 p.m. is the deadline for contacting me with feedback on the above proposal. I will consider and respond to any questions or comments raised before then (in collaboration with appropriate folks). Otherwise, this matter is closed and will become effective next week.

Thanks,

J Aaron

 

 Controling  A Meeting

Facilitate (v): The act of making things easy or easier.

Good meetings happen only when someone in the room understands how to facilitate. Some people do it instinctively, and others can’t even recognize when it’s being done. Like other interpersonal skills, people have different levels of awareness about the many ways interaction occurs and how to influence it.

Facilitating can be a semiformal role, held by a designated person who runs the show (often the PM), or by whoever called the meeting. Some teams have strong enough cultures of facilitation (meaning that many people have the skill) that they can switch who’s playing this role naturally in the course of conversation. But most of the time, on most projects, meetings are desperately in need of facilitation talent.

Building trust

Trust (n): Firm reliance on the integrity, ability, or character of a person.

“Trust is at the core of all meaningful relationships. Without trust there can be no giving, no bonding, no risk-taking.”

Terry Mizrahi, Director of Ecco (Education Center for Community Organizations)

Trust is built through commitment

When you make a new friend, and he tells you he’ll meet you somewhere, you take it on faith that he’ll be where he says, when he says. But if two or three times in a row he stands you up, and you end up watching a movie or standing in a club alone, your trust in him will decline. In effect, he’s broken his commitments to you. If it continues, your perception of him will change. You will no longer see him as reliable, and you will question your trust in him in matters of importance.

According to Humphrey’s Managing the Software Process (Addison Wesley, 1989), one of the central elements of well-managed projects is the leader’s ability to commit to her work, and to work to meet her commitments. Humphrey believes this is so important that he precisely defined the elements of effective commitments.

Trust is lost through inconsistent behavior

Eventually, people listened to me because of their confidence in my ability to have good reasons for my opinions.

Priorities make things happen

A large percentage of my time as a PM was spent making ordered lists. An ordered list is just a column of things, put in order of importance. I’m convinced that despite all of the knowledge and skills I was expected to have and use, in total, all I really did was make ordered lists. I collected things that had to be donerequirements, features, bugs, whateverand put them in an order of importance to the project. I spent hours and days refining and revising these lists, integrating new ideas and information, debating and discussing them with others, always making sure they were rock solid. Then, once we had that list in place, I’d drive and lead the team as hard as possible to follow things in the defined order. Sometimes, these lists involved how my own time should be spent on a given day; other times, the lists involved what entire teams of people would do over weeks or months. But the process and the effect were the same.

A fundamental law of the PM universe is this: if you can’t say no, you can’t manage a project.

No, this doesn’t fit our priorities.

No, only if we have time.

No, only if you make happen.

No. Next release.

No. Never. Ever. Really.

Know the critical path

Crtitical Path Methodology

In project management terminology, the critical path is the shortest sequence of work that can complete the project. In critical path analysis, a diagram or flowchart is made of all work items, showing which items are dependent on which others. If done properly, this diagram shows where the bottlenecks will be. For example, if features A, B, and C can’t be completed until D is done, then D is on the critical path for that part of the project. This is important because if D is delayed or done poorly, it will seriously impact the completion of work items A, B, and C. It’s important then for a project manager to be able to plan and prioritize the critical path. Sometimes, a relatively unimportant component on its own can be the critical dependency that prevents true priority 1 work from being completed. Without doing critical path analysis, you might never recognize this until it is too late.

Always have a sense for the critical path of:

• The project’s engineering work (as described briefly earlier)

• The project’s high-level decision-making process (who is slowing the team down?)

• The team’s processes for building code or triaging bugs (are there needless forms, meetings, or approvals?)

• The production process of propping content to the Web or intranet

• Any meeting, situation, or process that impacts project goals

 Be relentless

“The world responds to action, and not much else.”

Scott Adams

Summary

• Everything can be represented in an ordered list. Most of the work of project management is correctly prioritizing things and leading the team in carrying them out.

• The three most basic ordered lists are: project goals (vision), list of features, and list of work items. They should always be in sync with each other. Each work item contributes to a feature, and each feature contributes to a goal.

• There is a bright yellow line between priority 1 work and everything else.

• Things happen when you say no. If you can’t say no, you effectively have no priorities.

• The PM has to keep the team honest and keep them close to reality.

• Knowing the critical path in engineering and team processes enables efficiency.

• You must be both relentless and savvy to make things happen.

 

The simplest way to manage up is to initiate a discussion with your manager where you propose specifics for the following points.

• What I expect you, my manager, to do for me (e.g., giving guidance, warning me of things I need to know, supporting my decisions, pointing out areas where I need to grow)

• The resources I need to meet those goals, and who I need them from

• The level and frequency of involvement I need from you (No involvement? Quarterly reviews? Daily status reports? Weekly one-on-one meetings? Be specific)

By doing this early, you will know exactly how much support you can expect, and where problems will likely come from. Alarms should go off if your manager is unresponsive, vague, or defensive about committing to any of your requests. It means you may very well be on your own or are set up to fail, and that your manager is not actively working in your mutual interests.

In the end, proactive leadership in your own sphere of influence is the best way to grow your own sources of power. Initially, you might lose favor with your superiors for working differently than they do. But over time, people will like the playing field you’ve created. They will be happier and more effective working with and for you than with others. Unlike with the status quo of the rest of the organization, the quality of your team’s work will continually rise.

All is said in jest but what matters is, Which ones deliver on their vision? When a project is on the line, who actually gets the job done?Every team has a natural leader — and often that leader is not a team’s official manager. Your job is to get the team motivated. Once you do that, the natural leaders will emerge very quickly. If you keep an eye on the team, you can figure out who those natural leaders are — and then make sure that they’re happy and that they have everything they need to do their job. For instance, natural leaders need to feel that they have access to the company’s senior managers. Don’t forget: They feel like they’re changing the world — so you need to make them feel like you’re helping them do that.

There are easy ways that you can help them out. For example, encourage them to bypass layers of middle management and to send you email directly. Sure, that will piss off the people in middle management, but it’s better to piss off those people than to piss off your key project leaders.

arguments always centered on some problem that needed to be solved, and what the best approach would be to solve it. If there was a disagreement, he’d restate the goals and expectations, make sure everyone was still on the same page, and then lead a discussion of possible alternatives. Working for him always felt like a partnership. Decisions were made on the basis of their merit, and any point of view was allowed provided it added value to the discussion. He didn’t care if he was right or wrong, only that the best ideas survived.

He chose people that were self motivated and confident enough that he didn’t have to expend much energy figuring out how to get them to work hard. Then he created an environment where good ideas rose to the top, further encouraging smart people to want to contribute. The bossman made working for him feel like a proper relationship: he got something from us, and we got something from him. I think that this kind of management style requires more skill and savvy than a more hierarchical drill sergeant type of manager. Unlike the later, the former demands comfort with degrees of ambiguity, and the confidence to allow people to openly disagree, or intellectually trump, their manager. But from my experience, this open management style is the only way to have a “best idea wins” kind of culture.

It’s all about making actions and decisions that both clarify how people’s talents apply to the team goals, and working to keep the team happy, motivated, and focused in that application.

When people see that somehow you’re able to cultivate and grow smart people, you win more acclaim than if you presented the ideas yourself. I think if good ideas are in abundance, and the culture promotes and rewards their creation, there’s much less competition for credit for it.

Respect what talents they have, that you do not (and hire with this in mind)

I’m a fan of sports analogies to management, so here’s one: every team sport requires many different skills. No one player is the best at everything and winning games requires each player to understand their specific role, the roles others play, and how it all needs to fit together to work. Business or technical organizations are no different. Things only go well if everyone understands (and is comfortable with) their role, knows the roles of others, and has some understanding of how it all fits together. Good managers should be easily seen as coaches (not the Bobby Knight chair throwing type, but the John Wooden nurturing leader type), who value the different roles, and try to bring together the right kind of chemistry to make good things happen.

If you are a manager, it’s unlikely that you were born that way. For awhile you probably had the job that one of the people that works for you currently has. You used to be more specialized, and have a well defined expertise. This means that your natural bias will be towards over involving yourself in that role, and underinvolving yourself in the other roles people play on your team. It’s human nature. Perhaps you used to be a developer, you liked being a developer, and you think you’re good at developing. So when an engineering issue comes up that impacts marketing, interface design and localization, odds are you’ll tend to focus most on the engineering point of view, which might not always be the most important one.

Odds are also good that if you do this often enough, you will destabilize your team, undermine its other strengths, and lead you and the team to great shame and tragic ruin (Ok, maybe not. But it will impact what kinds of issues people bother raising in front of you). As the manager, your philosophical biases often become the team’s philosophical biases. You have to go out of your way to periodically allow your own points of view to be evaluated, questioned, and improved.

Sometimes the only way to make this happen is to bring an outsider in to evaluate the hidden biases an organization has, and who can make commentary and recommendations without fear of political recriminations. You can only have the best ideas surface if you’re drawing from a wide pool of perspectives, including those different or even in conflict with your own.

Another solution is this: First acknowledge that you have weaknesses, both in skills and in knowledge. Second, admit that you’re ignorance hurts not only the product or website, but the team itself. Third, get help in hiring experts for roles you are not familiar with, and go out of your way to involve them, and their perspective, in your decision making process. Deliberately hire first rate strong willed people to represent disciplines that you tend to undervalue. Force yourself to be on the top of your own game, and to make sure it’s not bias and ignorance that drive you, but good judgment refined by divergent perspectives.

Just as I must know the laws of Art to practice Design, I must also know psycology to be a good manager.

Are you a manager or a leader? Although you may hear these two terms thrown out interchangeably, they are in fact two very different animals complete with different personalities and world views. By learning whether you are more of a leader or more of a manager, you will gain the insight and self-confidence that comes with knowing more about yourself. The result is greater impact and effectiveness when dealing with others and running your business.

We are going to take a look at the different personality styles of managers versus leaders, the attitudes each have toward goals, their basic conceptions of what work entails, their relationships with others, and their sense of self (or self-identity) and how it develops. Last of all, we will examine leadership development and discover what criteria is necessary for leaders to reach their full potential.

First of all, let’s take a look at the difference in personality styles between a manager and a leader.

Managers - emphasize rationality and control, are problem-solvers (focusing on goals, resources, organization structures, or people), often ask question, “What problems have to be solved, and what are the best ways to achieve results so that people will continue to contribute to this organization?”, are persistent, tough-minded, hard-working, intelligent, analytical, tolerant, and have goodwill toward others.

Leaders - are perceived as brilliant, but sometimes lonely, achieve control of themselves before they try to control others, can visualize a purpose and generate value in work, and are imaginative, passionate, non-conforming risk-takers.

Managers and leaders have very different attitudes toward goals.

Managers - adopt impersonal, almost passive, attitudes toward goals, decide upon goals based on necessity instead of desire and are therefore deeply tied to their organization’s culture, and tend to be reactive since they focus on current information.

Leaders - tend to be active since they envision and promote their ideas instead of reacting to current situations, shape ideas instead of responding to them, have a personal orientation toward goals, and provide a vision that alters the way people think about what is desirable, possible, and necessary.

Now let’s look at managers’ and leaders’ conceptions of work.

Managers - view work as an enabling process, establish strategies and makes decisions by combining people and ideas, continually coordinate and balance opposing views, are good at reaching compromises and mediating conflicts between opposing values and perspectives, act to limit choice, and tolerate practical, mundane work because of a strong survival instinct which makes them risk-averse.

Leaders - develop new approaches to long-standing problems and open issues to new options, first use their vision to excite people and only then develop choices which give those images substance, focus people on shared ideals and raise their expectations, and work from high-risk positions because of strong dislike of mundane work.

Managers and leaders have very different relations with others.

Managers - prefer working with others, report that solitary activity makes them anxious, are collaborative, maintain a low level of emotional involvement in relationships, attempt to reconcile differences, seek compromises, and establish a balance of power, relate to people according to the role they play in a sequence of events or in a decision-making process, focus on how things get done, maintain controlled, rational, and equitable structures, and may be viewed by others as inscrutable, detached, and manipulative.

Leaders - maintain inner perceptiveness that they can use in their relationships with others, relate to people in intuitive, empathetic way, focus on what events and decisions mean to participants, attract strong feelings of identity and difference or of love and hate, and create systems where human relations may be turbulent, intense, and at times even disorganized.

The Self-Identity of managers versus leaders is strongly influenced by their past.

Managers - report that their adjustments to life have been straightforward and that their lives have been more or less peaceful since birth, have a sense of self as a guide to conduct and attitude which is derived from a feeling of being at home and in harmony with their environment, see themselves as conservators and regulators of an existing order of affairs with which they personally identify and from which they gain rewards, report that their role harmonizes with their ideals of responsibility and duty, perpetuate and strengthen existing institutions, and display a life development process which focuses on socialization. This socialization process prepares them to guide institutions and maintain the existing balance of social relations.

Leaders - reportedly have not had an easy time of it, their lives are marked by a continual struggle to find some sense of order, do not take things for granted and are not satisfied with the status quo, report that their sense of self is derived from a feeling of profound separateness, may work in organizations, but they never belong to them, report that their sense of self is independent of work roles, memberships, or other social indicators of social identity, seek opportunities for change (i.e. technological, political, or ideological), support change, find their purpose is to profoundly alter human,

economic, and political relationships, and display a life development process which focuses on personal mastery. This process compels them to struggle for psychological and social change.

Development of Leadership

As you can see, managers and leaders are very different animals. It is important to remember that there are definite strengths and weaknesses in both types of individuals. Managers are very good at maintaining the status quo and adding stability and order to our culture. However, they may not be as good at instigating change and envisioning the future. On the other hand, leaders are very good at stirring people’s emotions, raising their expectations, and taking them in new directions (both good and bad). However, like artists and other gifted people, leaders often suffer from neuroses and have a tendency toward self-absorption and preoccupation.

If you are planning on owning your own business, you must develop management skills, whether they come naturally or not. However, what do you do if you believe you are, in fact, a leader - a diamond in the rough? What can you do to develop as a leader? Throughout history, it has been shown again and again that leaders have needed strong one-on-one relationships with teachers whose strengths lie in cultivating talent in order to reach their full potential. If you think you are a leader at heart, find a teacher that you admire - someone who you can connect with and who can help you develop your natural talents and interests. Whether you reach glory status or not, you will grow in ways you never even imagined. Isn’t that what life is about anyway?