aroj.com has good professional looking resume examples

Aquent.com ’s   designsalaries.com

http://www.emurse.com/

I think there is alot of potential for a Group of C# modules that would possible be created as polymorphic Console Applications which could handle individual compliancy business rules and you could licence each one per discipline per vertical.

some ideas would be in these spaces:

• Accounting compliancy
• Forcasting Risk Assessment
• Sarbanes Oxley
• Pricepoint formulas

what do you think ?

Social Commerce is the new virtual buzz ! I have posted on like.com almost exactly a year ago and have since using it — I havent looked back !

Now some new powerhouses have begun to creep up. Wists, Kaboodle, StyleHive, ThisNext, Crowdstorm, Zebo & Wise.com also has a powerful product-vs-internet buzz ranking site.

It is a fact that more and more retail is going online, we all can easily earn ourselves a slice of the pie; “s-commerce” as I have coined here has truly become a critical cornerstone and is the continuing growth of the online shopping industry !

I have just built an ecommerce Paypal gateway engine (you can experience it — and buy things from it too — for ByGoneVideo ! ) I can churn the WAMP-based code for lots of different genres of merchandise and I will next engineer additional social community gadgets to integrate into the system… anyone have any best-of-breed ideas — please post !

This evolution of a commerce script is a good new business idea !

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 !

I am inspired today by CEO Chapman of Empower PR in Chicago.

I wanted to briefly state how much I admire this man’s business and his employees’ too for that matter on their stance on  a no “gossip ban”. I believe this is an exciting progressive step that everyone should professionally implement. In my limited experience gossip is an awful deteriorating issue which I have found many HR departments are much of the catalyst of the problem…

Adoption to such a standard for most businesses unfortunately may not be as effectively implemented as anyone would hope rather I am sure that CEOs will follow the trend and draft something for it which may be efficient but not necessarily effective. As many know in PR, marketing a speaking series is a powerful tool and can become a profitable business in and of itself.

I think it would be a cool PR move if a Professional with some time to waste on it could next structure gossip ban learnings into materials to be digestible for training and package it just right or publish a book and feature it on a circuit tour…

Just so everyone knows, if someone DOES take me up on this idea, I would be interested along with my cadre/consortium of professionals to fully support producing presentation needs on such a endeavor… Let me know if I can ever be of service…

Warmest regards,
JAaronAnderson.com

Michael Rosenblum on Internet Media
http://www.youtube.com/watch?v=BUXBpiwdsxU

https://accessnet.state.nj.us/home.asp

Starting a Business Overview

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.

Your resume is about YOU, your SKILLS and EXPERIENCE.

The COVER Letter is what you can DO for the EMPLOYER.
in it you should list out what you can do for the employer not rehashing your resume.

“I am adept in creating master brand strategies and trnslating product information into effective result oriented communication. I harness the powers of an integrated marketing approach and perfect positioning to leverage marketing dollars.”

EMPLOYERS do NOT want to hear how thier position can FURTHER your career, they want to know how you will earn them results and money! They want to know what you will be doing to earn your paycheck.

- finally always come from a proposition of value and not a place of need.