Conversations Products Catalog
Observation and conversation is another one of those tools and techniques that is self-evident. To assess team member performance, you have to observe it. I hope you've also learned how important communication is to the success of the project. This includes communicating with your team members. I know project managers who are reticent to engage their teams in conversation unless it's official project business. I've even known project managers who
With a few sketches of potential user interfaces, real design work can begin. An informal walkthrough of the sketches with engineers, testers, and marketers can begin the real conversations that lead to progress. An engineer can give an off-the-cuff recommendation to a designer about the work implied or suggest changes to the design that might make it easier to build. Many good questions will be asked in both directions. The engineer may also be able to make the designer aware of options that are technically possible but of which she wasn't aware ( Oh, with the new flux capacitor we're building, you can eliminate that screen ). The earlier this discussion can start, the faster the conversation becomes strong, and the more ideas that can be raised, considered, and reviewed. If the goals for the project are clear, and the problems to solve are identified, the design conversations that ensue will be good-natured. Disagreements will happen, but if everyone is trying to solve the same...
No matter which medium you use to communicate, your basic approach can affect the way your message is received and interpreted. As in the example above, a phone conversation, a note, and a personal visit were all effective ways to transmit message content. The choice to not communicate in person,
Sometimes, you will need to say no in direct response to a feature request. Other times, you'll need to interject yourself into a conversation or meeting, identify the conflict with priorities you've overheard, and effectively say no to whatever was being discussed. To prepare yourself for this, you need to know all of the different flavors that the word no comes in
The COS consists of two conversations. The first one is driven by the requestor and the second by the provider. Figure 14.2 is a schematic of the process. Let's look at the two types of conversation Requestor-driven conversation. The requestor states and describes the request using their language. The provider makes sure he or she understands the request by using questions and eventually feeding back the request in his or her own language. At some point in this conversation, you want the requestor to be able to say to the provider, You clearly understand what I am asking you to do. The conversation now shifts to the provider-driven conversation. Provider-driven conversation. The provider responds by stating and describing what can be done to meet the requestor's request. The requestor asks questions to frame the answer and eventually describes the response in his or her own language. At some point in this conversation, the provider is able to say to the...
The basics of communication are the creation of documents necessary for the fulfillment of a project and holding meetings to distribute these documents. To deepen understanding, two-way conversation is necessary and is usually implemented in the form of a meeting, if more than one division is involved. During a project, different meetings should be held, as listed below
One day, as Dave is passing through the cafeteria, he catches wind of a spirited conversation a few team members are having at a table in a far corner. He is stunned by what he hears His knees turning to jelly, Dave makes his way back to his office and does a quick calculation of how much time has been lost with team members waiting on missed deliverables, which are apparently not on anyone's radar screen. Then he realizes that this cafeteria conversation included only three project team members. Would he have to multiply the time lost by three or four, if all members feel the same way
Significant learning must occur before an organization embarks on the transformation to teams. A framework and link (i.e., context) need to be established between the current organizational state and the reason for having the conversation about the desired state. The context thus provides the basis for the conversations that are necessary for building a strong foundation for change. The graph does not provide a linear or absolute view. It is intended to generate thoughts and guide related dialogues about teams and to help develop a spectrum of opportunity that more closely resembles a particular organization. There is no right or wrong place to be on the graph, no better or worse arrangement of groupings. The important point is for an organization to have the conversation about the range of possibilities and how teams could fit into the organizational structure. Even in the lowest quadrant of opportunity, an organization can achieve benefits of the team structure by polishing...
The methods used to manage negotiation and conflict vary depending on the scope of the project, the concerned parties relationship to each other, and the seriousness of the disagreement. Methods range from simple conversation and meetings to formal arbitration in a court of law.
Most important because the mannerisms, gestures, tone of voice, spirit, and inflections of the person speaking often communicate more than the spoken word. One needs to pay particular attention to his or her gestures and expressions, as they will convey more about the intent of the conversation than the spoken word.
E-mail is good for one-on-one communication, but there are times when a conversation benefits from wider input. For example, you might have a group of developers and testers who want to discuss how a particular feature should work, or a group of customers with feedback and suggestions for future versions of the application. To handle this sort of many-to-many communication, FogBugz includes support for online discussion groups. FogBugz discussion groups are simple. You can set up any number of groups on your server and give them each a distinct name. Each group contains threads, and each thread contains messages. Messages are presented as a chronologically ordered list, without any branching this makes it easy to catch up with any conversation by starting wherever you left off.
Above any other conversation, e-mail, or promises, the details of the project contract are paramount. The project manager consults the contract, not only to confirm that the vendor has lived by its obligations, but also to confirm that the project manager's organization has held up its part of the bargain. Sometimes, and they are not fun times, the vendor didn't live up to the agreement and the contract was cancelled. Contracts can be cancelled for any number of reasons poor performance, schedule and or cost overruns, quality issues, and more. Whatever the reason, the documentation surrounding the cancellation of the contract is included as part of the contract closure, and this information is also included in the project archives for future reference.
The client and the team should spend most of a day in frank and honest conversation, considering all of these factors and then agreeing on the functionality that will be planned for the next cycle. Do not underestimate the value that can come from the sharing of learning and discovery. That will be your most important information because it really helps both parties understand what this solution is really all about and what should be offered as a final solution. This part of the process is no trivial task.
Effective communication occurs when a clear transfer of knowledge exists between you and at least one other person. You have an idea and the other person, through your conversation, gets what you're after. You get an e-mail and you understand what the stakeholder wants. You facilitate a project meeting and your project team follows your agenda, the information is presented, and everyone is in synch on what to do next. Everyone, from members of the project team to project stakeholders, must communicate openly and accurately. Unless you facilitate each conversation with a mission to understand exactly what the person speaking is trying to convey, you're facing a potential communication meltdown. So how do you ensure accurate communication Here are some tips 1 Document your conversations in e-mails, memos, or meeting minutes. If you put the conversation points in writing, the party with whom you're communicating has an opportunity to clarify various points if there are any...
Informal verbal communications are conducted to ensure the day-to-day operations of the project are moving ahead as planned. They are generally uncontrolled and unmonitored, but that does not mean that they are unimportant. As discussed in Chapter 2 on ad hoc conversations, there is still a need to ensure that these conversations (particularly when they involve customer, client, or sponsor personnel) are limited in scope. Whenever the conversations stray into commitments to a customer, reallocation of resources, modification of contractual arrangements, or anything requiring formal approval, the conversation should be redirected to a more formal setting (such as a meeting). Other limitations (such as limitations on the nature of conversations about other project stakeholders) may be ordained by the project team, but may be far more difficult to enforce.
The first tour I took of the engineering space at Servicelst was downright depressing. People were either housed in offices with closed doors or exiled to cubicles. Most people were alone in their offices or cubicles, often staring at a computer monitor. There was no conversation, no hum of activity, no feeling of a group of people undertaking work that they were excited to do. A lethal arrangement of space and walls had isolated the employees of Servicelst. Everything felt different by the time the second Sprint review rolled around, and it was clear that there was positive change afoot by the subsequent Sprint retrospective. People were talking and sharing laughter and lively conversation filled the workspace. I heard detailed questions and responses. I heard a buzz that filled the entire floor and people engaged with each other in mutually working to understand and solve problems. A common theme during the Sprint retrospective was how much the team members enjoyed working on this...
Despite how obvious it is that you need to have a positive relationship with someone in order to have a good conversation with him, people are rarely rewarded for their skills in doing so. Those informal chats and conversations Ken and Joe invested time in were not a way to kill time. Those conversations were investments in people and information, giving Ken and Joe This made it easier to cut to the chase without being rude, or even to make exceptional requests of people that ordinarily would be rejected. In matters of opinion, they had built enough trust to get honest opinions from the right people in a casual manner, and, if so inclined, they could incorporate those suggestions and ideas into their own thinking well in advance of larger discussions. In short, through those informal conversation and relationships, Ken and Joe were ahead of the rest of the team. They knew more about what was going well and what wasn't, and they had more influence on it through their investment in...
(4) SITUATION ORIENTED STRATEGIES Situation oriented strategies are coping strategies designed to allow the communicator to redefine a situation so that they no longer feel that they are a victim. Examples include the use of humour, withdrawing from conversation or ignoring statements.
The entire project team meets every morning for about 15 minutes. These are stand-up meetings where status is reported. Each task leader should state where he or she is with respect to the time line (ahead, on target, or behind) and if his or her team is ahead or behind, by how many hours or days. If the team is behind, they should briefly state their get-well plan. If anyone in the meeting is able to help, that person should say so and take that conversation offline. Problems and issues are not discussed in the team meeting except to
I had been running these conference calls for a month, and I couldn't have a conversation because Jack was eating lunch, Pierre was eating dinner, not all the people were on the call when they needed to be, and more. It was a disaster. I finally laid down the law.
Having never worked with this manager before, you are unsure about which conflict resolution mode would work best. You decide to wait a few days and then set up an appointment with the department manager without stating what subject matter will be discussed. You then try to determine what conflict resolution mode appears to be dominant based on the opening remarks of the department manager. Neglecting the fact that your conversation with the department manager might already be considered as confrontation, for each statement shown below, select the conflict resolution mode that the department manager appears to prefer. After each member of the group has recorded his personal choices in the table on page 420, determine the group choices. Numerical values will be attached to your answers at a later time. Allow ten minutes for this part.
After getting initial cost estimates, your customers and bosses will send you back to the proverbial drawing board for more research and planning. Eventually, you'll find yourself having a conversation in which you justify all your costs and your clients and bosses attempt to find areas to cut costs in your deliverable. You may go several rounds before everyone is finally in agreement with the project cost estimate.
Those conversations were not ethereal or anecdotal things. In each of those conversations, I was doing something directly related to the goals of the project. This goes beyond the abstract importance of good relationships. Every time I answered a question at my door, negotiated with another organization, or argued for resources for my team, I was doing as much as any developer or tester to move the project forward. I was enabling them to write code, find bugs, and do 1,000 other things faster or easier than they would have otherwise. My point is that if you carefully examine the conversations you have with people, and consider their impact on the project, you'll generally find every conversation contributes to one of the following things So, even when you tire of clearing roadblocks, answering questions, or checking in with various people for different reasons, remember that the effort you put into those things is not wasted or of low importance. As long as you can connect those...
Power you need, and you ask him for it. Depending on the approach and style you've identified (see the previous list) this could be an informal conversation, an email, or a meeting you've put together exclusively for this purpose. The more formal you make the request, the greater the odds are that other people will be involved in the discussion. The less formal, the more direct your conversation and request might be. In Figure 16-5, A represents the person with the power you need, and B, C, and D are other people on your team. 188.8.131.52 The conversation Optionally, this can be combined with the direct request (as illustrated in Figure 16-6). Other options include how you make use of the influence you've gained. It may not be necessary to have B, C, and D actually in the room, or even to ever talk to A about the issue in question. As long as you have their approval, you may be able to speak for them, telling A I think we need to cut this feature. I spoke to B, C, and D, and they all...
IS managers are responsible for building and sustaining the position that teams are the first line of assistance for all aspects of day-to-day operations and service provision. This can be accomplished through discussions with customers and suppliers about the new structure and its meaning for relationships and respective roles. The transition to smooth team interaction with customers and suppliers is not effectively handled in a single conversation, however, but rather through consistent and repetitive messages from managers delivered both proactively and reactively. The effectiveness of the transition and the minimization of this misery depends on the managers' ability to stand by the structure change and the teams while maintaining strategic and long-term relationships with the supplier and customer communities.
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.
One myth of project management is that certain people have an innate ability to do it well, and others do not. Whenever this myth came up in conversation with other project managers, I always asked for an explanation of that abilityhow to recognize it, categorize it, and, if possible, develop it in others. After discussion and debate, the only thing we usually identifiedafter considering many of the other topics and skills covered elsewhere in this bookis the ability to make things happen. Some people are able to apply their skills and talents in whatever combination necessary to move projects forward, and others cannot, even if they have the same or superior individual skills. The ability to make things happen is a combination of knowing how to be a catalyst or driver in a variety of different situations, and having the courage to do so.
The main principle is that every communication external to the team (with your managers, users or vendors) must be either written, or confirmed in writing. At first, this may seem excessive and bureaucratic, but you'll be amazed how quickly it seems natural. On the other hand, it only takes one lost or mis-understood telephone conversation with a user to cause considerable disruption to your careful plan In the same way, if s important to minute meetings, or at least their conclusions. Writing can't be your only form of communication, but it must be the formal way.
After allowing this conversation to run on through lunchtime, Dave throws up his hands and asserts that the scope as written in the project proposal was the one they were going to live with. End of story. As they break for lunch, team members express varying degrees of frustration, confusion, anger, and resignation. Most leave feeling that their questions and concerns had gone unheard, and that they will have far less influence in the project than they had hoped.
The spectrum of opportunity depicted in Exhibit 1 provides a starting point for the assessment of organizational culture. A valuable exercise for IS managers would be to plot the groups or functions within an organization in the appropriate quadrants. An enlightening conversation is sure to ensue if managerial staff and a cross section of employees are asked to do the same. The learning potential is great regardless of
Unhappy over the department manager's memo and the resulting follow-up phone conversation, you decide to walk in on the department manager. You tell him that you will have a problem trying to honor his request. He tells you that he is too busy with his own problems of restructuring his department and that your schedule and cost problems are of no concern to him at this time. You storm out of his office, leaving him with the impression that his actions and remarks are not in the best interest of either the project or the company.
Comparative evaluation can take place only if you've clarified the problem or issue to be decided. You will also need a sense for what aspects of the outcome are desirable (ship sooner, improve quality, make the VP happy, etc.). There should be every incentive to borrow words and phrasing from the vision document, specifications, or requirements lists. Those documents reflect high-level decisions that have already been made, and you should reuse as much of their value as possible (which is precisely what those documents are for). Sometimes, a conversation with the client, customer, or author of those documents is just as good as (or better than) the documents themselves.
But instead of micromanaging them ( Do this. No do that. No, do it this way. Are you done yet How about now ), I just made them understand that I was there to help them prioritize when they needed it. Because they didn't have the project-wide perspective I did, my value was in helping them to see, even if just for a moment, how what they were doing fit into the entire project. When they'd spent all day debugging a module or running unit tests, they were often relieved to get some higher-level clarity, reassurance, and confidence in what they were doing. It often took only a 30-second conversation to make sure we were all still on the same page.
Using the information you have, periodically take your best guess at what the direction shift might be (Support for a certain technology A new feature A new goal ), and sketch out what adjustments you'd need to get there. This can be very roughfor example, having a brief conversation with a lead programmer about what might be involved. Fred, what would we have to do to support the 2.0 API set in addition to the ones we already use Your goal isn't a new battle plan, it's having some sense of what that road will look like should you and your team have to take it. Re-examine your prioritization list for work items (see Chapter 13) and see if you've already done some thinking on the new work you might have to take on. But there are cases where it will be straightforward. For example, a programmer might have already considered that direction or have a reasonable opinion based on her understanding of the code. To prepare your team in this way, it might cost nothing more than a five-minute...
Ad Hoc Conversations The most common verbal communications medium is the traditional conversation. It is often suggested that more project communication goes on at the coffee machine than is ever conducted in meetings. Ad hoc conversations facilitate the social and business interactions that make projects possible. They are often the foundation on which much of the project is built. Their purpose is to fill in the gaps of understanding left by other media and to affirm a common understanding of all aspects of the project environment. Such conversations are used whenever and wherever two project stakeholders meet, and they are used to clarify project information as well as individual interpretations of that information. In many instances, the clarity derived from a casual conversation in the hall provides more depth than can be generated in the work breakdown structure. Because these conversations are not planned, however, they should not be relied on as a key supplement to other...
Along with naming conventions, you'll also have to agree on the repository for the data. If you're implementing an EPM software package, then this part of the conversation is quite easy. The new system will have a set method of storing data, usually in a commercial database like Microsoft's SQL Server. Then all you'll have to organize is choosing the single location for that data to reside. Different groups may lobby for why their need for project management is so unique that it's absolutely impossible for them to comply with a single repository of their data somewhere else. These various interest groups will have to be dealt with one at a time. Your first mantra for deploying project management has to be all project data, one location until there is broad compliance.
The technology progress report was posted on the door of the team room, where it was visible to anyone walking by. A copy was delivered to Jim weekly, keeping him up-to-date on progress more frequently than once a month. When Jim met members of the MBITWeb team in the hallways and asked about progress, the conversation was held in terms of the services and service names on the technology progress report.
This conversation provided the team with some background. The team members now wanted to know why I was concerned about the code not being checked in. I said that code is often checked at a higher rate than usual so as to facilitate frequent builds. A build is a compilation of all of the code in a system or subsystem to validate that all of the code can be pulled together into a clean set of machine-readable instructions. The build is usually followed by automated tests to ensure that all of the functionality works.
Managers who distance themselves from teams to allow for the natural growth of the group sever the informal, day-to-day conversations of the previous organizational relationship. Team members may infer that the manager does not care what the teams are doing or if they are successful. In addition, because the teams are more distant from what is happening in the organization, they end up feeling somewhat abandoned and isolated. IS managers must maintain informal avenues of communication as a source of information exchange and a demonstration of their interest and stake in the team development process. Misery Management. Although these managerial actions can stop team progress immediately, there is tremendous opportunity for learning in each of them. The IS manager's challenge is to remain open and somewhat vulnerable to learning while challenging the team to participate in a successful conversation on inferences and actions. One strategy is for the manager to...
The project sponsor, Victor, requested a geographic information system (GIS) as part of the requirements of this project. The hope is that errors will be eliminated and commissions will be processed correctly. The sponsor is hoping that Ryan's internal team can write the GIS that will tie to the accounting system. Let's drop in on Ryan and Victor's conversation.
John, a project manager on my team, was ready to take on more responsibility. So, when the time came to reorganize the distribution of work on my team, I managed to give him an area I had been responsible for in the past. After the appropriate discussions with John and Steve (the programmer on the area), I handed the responsibility off to John. A week later, Steve came into my office asking for PM help with the area. While I listened, I tried to figure out why he was talking to me and not John. I interrupted him Steve, why are you talking to me about this Well Scott, you used to own this, didn't you Yes Steve, but John owns it now. Did you talk to him He shrugged. Steve, go talk to John, I said. He's smart. He's good. Trust him. Steve came back a few days later, and we had a shorter version of the same conversation. But after that, I never heard from Steve again (at least not about this).
Second, we make commitments all the time. In every conversation we have in which we ask or are asked to do something, and agree to a timeline for it, we're making a commitment. This includes simple statements such as Hey, I'll call you after lunch or I'll read that draft by tomorrow. Two people may have different ideas on how serious the commitment is, but there is rarely any doubt that some kind of commitment has been made. The less seriously we take our commitments to others, the greater the odds their trust in us will decline. There
He then did the second most unexpected thinghe asked me for my opinion. He gave me a chance to offer my own logic and perspective on the decisions he had to make. Right then, I had my first political epiphany this stuff is hard, really hard. By asking what I thought (and listening to what I said), he defused all of the animosity and finger pointing that usually comprised my attempts at political thinking. He made me actually consider the issues and people involved. And when I did, I froze. Like being thrown into oncoming highway traffic, I didn't know where to start it all seemed terrifying. I still remember staring at my half-eaten sandwich, failing to find anything intelligent to say. The conversation moved on, lunch ended, and I went back to work. I've learned much since then about how organizations function, but I look back at that day as an important change in perspective. Here are three key points I've learned since that day
The choice of medium is crucial in a communications model. As Marshall McLuhan emphasized in his classic work, Understanding Media The Extensions of Man 7 , the medium is the message. Firing a team member via e-mail is considered a violation of conventional business protocol. Firing a team member over a loudspeaker would be even worse. Firing a team member in a one-on-one conversation, off-site, might be considered reasonable and fair. The message is the same. Only the media change. Selecting media in the communications model is a critical issue, because the media can determine how the information is filtered, decoded, and received.
A collection of summarized conversations from Weinberg's SHAPE discussion group. I loved this book. It captures the spirit and energy of being in a conversation with a bunch of very smart and experienced people who are generous about sharing what they know. They cover many of the topics in software project management from project inception, schedules, conflict, and management politics. The book is short. It's based on conversations, so it's more pith and nugget than theory and playbook.
Communications between persons are carried out verbally and nonverbally. Verbal communications are in the form of oral and written messages. Oral communications can be carried out through dialogues, meetings, negotiations, presentations, or telephone conversations where the main part of the information is transmitted through vocal signals. Written communications can be realized through documents in the form of letters, instructions and orders, and regulations and statutes when one person transfers signals to another person in written form.
Have you ever attended a meeting that reminded you of a three-ring circus There was no agenda, one guy was talking on his cellphone, several people were having side conversations, you weren't sure of the purpose of the meeting, and not only that, but the donuts were stale Don't let this happen to you. Hosting a successful project meeting is not that difficult, and requires just a little planning and thoughtfulness.
Our project teams come together temporarily to solve a series of problems. As the group learns to work together and struggles to find new solutions, they are likely to disagree time and time again. Though such disagreement is a sign of a healthy dialogue, not everyone is used to or comfortable with this type of disagreement or conflict. The listening skills we have described here enable the people to use respectful conversations as they discuss ideas, maintaining relationships while pursuing the best solution. To the degree that a team leader can teach these skills, it can help the team move more quickly through Tuck-man's Storming phase.
The transition is a time for the people on both sides to become acquainted with each other. Full discussion and conversations are encouraged during this period to try to establish working relationships that will help in the continuing operation of the contract. The liaison representatives of the client and the vendor should take the lead in coordinating the design of the transition plans, as they will take a major role in their implementation.
FogBugz lets you set up both private (available only to logged-in users) and public (available to anyone who can see the server via the Internet) discussion groups. Private discussion groups are a great way to communicate in your team. Unlike private e-mail, once conversations are captured in a discussion group, they will always be visible and searchable, capturing valuable development knowledge for posterity. In addition to keeping a visible history of a conversation, FogBugz also lets you link items in discussion groups to cases so that you can make sure somebody deals with each customer problem, bug report, and feature request. Figure 5-15 shows a discussion group in action. This is the view that a user logged in to FogBugz gets. As you can see, anyone can contribute to this public discussion group. FogBugz users can turn posts into cases and take other actions that I'll discuss later in this chapter.
Carefully asked questions are one way to lead difficult conversations in useful directions. As an example, I had this recurring experience with logic professors that forced me to pay attention to how I asked questions. It would start with me asking something like, Can you explain this one part of Godel's incompleteness theorem The professor would answer, Certainly. You see, all proof systems can be reduced to an essential set of characteristics defined by the core recursive primitive functions. I'd say, Uh, OK. That's nice. But can you explain this one line here and I'd point to this tiny line in the proof, circled in thick red ink and with a giant question mark next to it. The professor would nod his head and say, Oh, that, of course. . Well, the history of logic proof systems stems from the noble attempt to express aspects of existence through a verifiable system I'd say, Oh, god. No, this here . What does it mean How does it relate to the line above it He'd answer with, Certainly,...
Such interviews are not only useful when you start working in a new network management job or as a facilitator in a new context. Conducting such interviews will notably improve your capacity for extracting meaningful information from ordinary conversations with relevant people, particularly because the interviews develop your capacity for active listening and cross-checking (triangulation) information from different sources. Both capacities are as important for managers as they are for facilitators.
The resident engineer should have spent some time before he goes to site examining the contract drawings and specifications, and there should have been an opportunity for him to have conversations with the designers. He should get to know how the job has been designed, so that he is able to make intelligent suggestions if the conditions revealed during the course of construction differ from those expected. He should make a file of all information which is basic to the job, such as
While a ROM estimate is nice for conversations, it's impossible to use for any substantial software project plan. ROM estimates are little more than wishes and blue sky. In order to create an accurate estimate, or at least a more accurate estimate, you need more information. The next level of estimating for a project is to create a budget estimate.
Optimization of the portfolio and discussions between those within the organization who have different experiences and perspectives. Ultimately, people, rather than data, make decisions. However, a thorough analysis of the strategic alignment of the portfolio will create a good first cut of the projects for the business to implement and will start the discussion with a strong foundation. As conversations progress, what-if analyses can be done to support different sets of the projects and to examine the business impact. The goal is not to replace manual selection with a metric-driven process, but to supplement ad hoc discussion with more formal modeling of the optimal portfolio, given the strategic goals of the business. Given the complexity of the process, adding some mathematical rigor to it can be enormously beneficial.
Social networking started as a consumer technology, with tools such as My Space, LinkedIn, Windows Live, and Facebook being examples popular in North America and Europe, with the addition of Friendster and Orkut in Asia. Similar concepts are being used by firms within the workplace to provide informal means of information through one-line status updates, sometimes called microblogs. Microblogging provides an easy way for individuals to stay up to date on topics. These tools provide greater context on an individual's role and function within the organization. The value ofthis technology, to both the employee and the organization, is to increase the reach of what were previously informal and ad hoc water cooler conversations to enable colleagues who might be working on similar issues to identify overlap where there might be opportunities to collaborate or get help from a much broader section of the employee community, where previously expertise would have been much harder to identify.
To determine what types and levels of training are needed. An initial perspective on training needs can be accomplished through surveys, meetings, and even informal conversations with project managers and other project stakeholders. Their project management experience and insight into individual and group skills, knowledge, and competencies could be sufficient to identify some fundamental training needs. In particular, the PMO could convene a select group of managers to discuss and deliberate current performance capabilities and to identify discernable project management training needs related to individual comprehension of concepts, application of processes, use of tools, etc. The PMO then can compile the information collected to plan a simple training solution.
Process as well as in the products of the team. Those members who are laid-back should be encouraged to participate and bring their thoughts and ideas to the forefront. Lack of participation can be a signal of some type of dysfunction in the team the leader should be particularly sensitive to the non-participating team member, following up with one-on-one conversations to see if there is some type of problem lurking in the background. The full-participation team is very likely to be a high achiever with solid relationships between team members and the leader.
Interviews Interviews are typically one-on-one conversations with stakeholders. Interviews can be formal or informal and generally consist of questions prepared ahead of time. The advantages to this tool are that subject matter experts and experienced project participants can impart a lot of information in a short amount of time and typically have a good understanding of the features and functions needed from the project deliverables. You should record the responses during the interviews and don't be afraid to ask spontaneous questions as they occur to you during the interview.
While I was studying computer science at Carnegie Mellon University, it was common to talk to professors and students about new products. We'd always focus on what components these new software products used and how they compared against what could have been. Value was implicitly defined as quality of engineering how reliable and performant they were or how much of the latest technology they took advantage of. Generally, we thought everything sucked. Exceedingly few products stacked up to our critiques. We wondered why the marketplace was packed end to end with mediocrity and disappointment. We'd even invent geek conspiracy theories to explain the evil decisions, which we thought were made against engineering purity and thus made little or no sense to us. Often, we'd focus blame on the marketing departments of these companies(3) (not that many of us understood what marketers did). Even in my first few years in the industry, the same kinds of conversations took place again and again....
Visions earned their name for a reason they are supposed to appeal to our capacity to imagine and visualize a specific kind of outcome. By looking at a picture, we absorb many levels of information all at once. For many complex concepts and ideas, pictures provide faster access and greater clarity to more people in less time than words. I've had dozens of conversations in my office with programmers or architects who are struggling to clarify points of an argument, only to end when one of us finally goes to the whiteboard, quickly sketches
In the minutes of the next meeting it is noted 'Acoustics are extremely important people are busy, lots of walking, talking and telephone conversations.' In the steering committee of February 10th, 1994 the architects of MVRDV present a note 'Noise absorption inside the building' in which they write 'Conclusion noise absorption is solvable with 60 mats (on the floor), with furniture and with curtains.' As a clubhouse or factory it is quite good, but thinking for a moment from time to time, having an undisturbed telephone conversation or writing an article, is not possible.
The project manager is usually the expediter of the status meeting. As such, it's your job to use status meetings wisely. Don't waste your team's time or the stakeholders' time either. Notify attendees in writing of the meeting time and place. Publish an agenda prior to the meeting, and stick to the agenda during the meeting. Every so often, summarize what has been discussed during the meeting. Don't let side discussions lead you down rabbit trails, and keep irrelevant conversations to a minimum. It's also good to publish status meeting notes at the conclusion of the meeting, especially if any action items resulted from the meeting. This will give you a document trail and serves as a reminder to the meeting participants of what actions need to be resolved and who is responsible for each action item.
As far as the daily work of planning is concerned, there's no magic way to go about doing these kinds of collaborative tasks. People are people, and it's impossible to skip past the time it takes to get individuals who are initially of different minds to come together, learn from each other, and make the arguments or compromises necessary to move things forward. There will be meetings and discussions, and probably the creation of email distribution lists or web sites, but no secret recipe of these things makes a big difference. Be as simple and direct as possible. The leader sets the tone by starting the conversations, asking the important questions, and making sure the right people are in the room at the right time. However, there are three things to keep in mind
Every organization has different considerations to make in how they plan projects. I can't offer a simple, five-step plan for how to get from day 1, with no vision, to day 20 (or 5 or 50) with a completed and fully sponsored vision. Depending on how much authority you do or do not have, it may take considerable time to get all of the necessary approvals and have all of the needed conversations to pave the way for the project. Part of this process must include a presentation of the key ideas, and the draft vision, to the entire team (a.k.a. all-hands meeting) early enough that it is not a complete pretense, but scheduled late enough that there is something substantive to say. While this is scary for new leaders, if a meeting is held at the point in time when core ideas are strong but some questions remain, the opportunity is created for everyone on the project to see the vision as something alive and accessible. They won't reject it if it's something they can still influence and...
Successful projects rely on execution. Plans are meaningless if the team does not carry through. Leaders set the tone by keeping their promises and delivering on their responsibilities, and they expect the same of every team member. Holding team members accountable can require some tough conversations and real consequences for nonperformance. It is not the best part of a leader's duties, but we owe it to the team to make sure the efforts of some are not diminished by the nonperformance of others.
For each kind of power you need, identify the person that can give it to you. The org chart or hierarchy is an easy place to start, but use it only to refresh your memory on the players involved (see Figure 16-4). Then ask around to find out who is most actively responsible for what kinds of decisions (on small teams, it should be obvious, but if you're unsure, ask). Use people who are committed to support you to help sort this out your manager, your peers, or reports. It shouldn't take more than a few conversations to identify the people you need. Sometimes, it's better to seek this kind of information indirectly because you don't necessarily want to approach the person(s) in question without a plan. (Avoid odd behavior, such as Hi Fred. Are you in charge of deciding who gets new laptops Yes, why Oh, just curious. Bye. )
You are the manager of a research group that is developing a new chemical material. You hire a person from a competing company who has a great deal of expertise in this area. The person contributes greatly to the progress of your project. During conversations with the person you determine that many of this person's ideas were developed by the competing company. What do you do
The methodologies used to transfer information among project stakeholders can vary significantly. For example, a project team may use techniques from brief conversations all the way through to extended meetings, or from simple written documents to material (e.g., schedules and databases) that is accessible online as methods of communication.
The manager leaves his or her office and starts walking around the project team office space. When a member of the project team is approached, the manager says something like, ''How was your golf game this week '' (Of course, the prudent manager would know that the person actually plays golf.) The manager opens up the conversation with a casual statement, and the team member begins to talk about his or her latest escapade on the golf links. Human nature demands that the team member change the conversation in a short time. Because the team member will not want to excessively talk about his golf game to the project manager, he soon will switch to discussing the project. When this happens all of the anxiety that is often present disappears, and free and honest communication takes place. If the manager had taken a different approach to this conversation, the results might have been different. If the project manager had come to this team member and said, ''Hey John, how are things going on...
It is becoming obvious that American competitive business culture does not encourage, develop, or sustain lean, and it is incompatible with the needs of the lean workplace. It might be said that these cultural beliefs are the internal success rules, almost impossible to change because current leadership has achieved its success using them. American managers often miss inputs from others in the conversation who are not as insistent or Type A. They are prone to overuse authority and often miss out on ideas from subordinates and others in the workplace because they are more competitive than cooperative. It is clear that one of the critical changes that will be required in the American lean workplace is for American managers to change their competitive management style. In order for American lean to be widely successful, we will need to develop and adopt a set of American-style lean cultural principles.
On the other hand, there are two features that are present in many discussion groups that FogBugz doesn't implement e-mail notification and branching conversations. Both of these are deliberate omissions. If you allow people to subscribe to a conversation via e-mail (usually implemented with a checkbox that says something like e-mail me if people reply to this post ), you've just removed the incentive people might have to come back to the discussion group. The result is that conversations will peter out quickly, and you'll have a hard (or impossible) time building any community. Eliminating this one little checkbox encourages (OK, forces) people to come back. While they're back, they might read a few more posts and contribute a few more of their own. Branching conversations seem reasonable to programmers let people reply to any post in a discussion and start a new thread of discussion from there. But if you implement branching, you'll find two things. First, it's incredibly hard to...
Having had this argument before, I smiled. I asked him if he'd make the same claim about the engineering plans for the hi-rise apartment building he lived in or the three-story highway overpass he drove on to get to work. But apparently he had heard this question before, and he smiled right back. He said that while he was glad those things were planned in great detail, he didn't think working with software was quite the same as working with the laws of physics and construction materials. We quickly agreed on two points. First, that compared to traditional engineering, software is more flexible, easier to change, and rarely has people's lives at stake. But, we acknowledged that because we faced complex engineering challenges, had a team of people depending on our decisions, and had budgets and deadlines to meet, we needed more than our memories of hallway conversations to make sure the right things happened. We also agreed that what we needed for our project was something suited to the...
Richard can build on this group of interested project managers with some light structure to foster growth and collaboration. Examples of this include the creation of a freely accessible internal project management portal with the latest academic thinking, driving mentoring for less-experienced project managers, or hosting a speaker series with leading thinkers. Bringing project managers together and exposing them to the latest research and ideas in project management can quickly spark innovation and a lead to a lot of Wouldn't it be cool if conversations among project managers, especially in organizations with smart, entrepreneurial employees. From that point, it is possible to start to discuss tools and processes for realizing these ambitions.
In the future, it is likely that these tools will become more integrated with project management systems. Today, information can be pushed down from project management systems into these tools and real-time updates can be applied to the project plan automatically based on how work is progressing, but little information is rolled up to surface individual work at the team level and to eliminate duplication of effort and facilitate conversations between individuals, who may be working on similar topics but are not aware of it. This is particularly acute for small tasks, which may not be part of a broader project plan. If these smaller tasks are not tracked, individuals will have trouble managing their work and resource management becomes challenging because availability is less meaningful if someone appears free but is spending time on work that is not captured in the portfolio system.
Hallway conversations, or while the employee is performing routine tasks. Many of these improvements can be made by employees on their own without the need for additional resources. Some of these ideas might entail 20 minutes of work to implement some might require a 20-year effort. Some ideas might not merit any action when compared with other business options that meet the same need.
Our dream team is based on a combination of people skills and technical competence. Although we like to be around happy, friendly people, we can accept grumps who can deliver what they promise any day. On the other hand, you may have the most skilled programmer or developer on your team, but he can't seem to hold a conversation so that anyone can understand him. Both skills are important. Your team members need to have technical expertise, but they also need to know how to play well in the sandbox with others. If you have the control over who works on your team, you need to figure out the most productive team makeup.
APF begins with a stated business problem or opportunity. This beginning is the same as TPM. A request has been made to develop a solution to the stated problem or opportunity, and that request has all the earmarks of a project. At this point, we are not at all sure what kind of project this might be or how we might approach it from a methodology perspective. A Conditions of Satisfaction (COS) conversation takes place between the requestor and the provider to define more clearly exactly what is needed and what will be done to meet that need. The result of that conversation is a decision as to which project management approach will be followed traditional (covered in Part I), extreme (covered in Chapter 19), or APF. We have decided that APF is the approach to be taken, so a project scoping document, specifically, a Project Overview Statement (POS), is written.
Training includes all activities designed to enhance the competencies of the project team members. Training can be formal or informal. Examples of training methods include classroom, online, computer-based, on-the-job training from another project team member, mentoring, and coaching. If project team members lack necessary management or technical skills, such skills can be developed as part of the project work. Scheduled training takes place as stated in the human resource plan. Unplanned training takes place as a result of observation, conversation, and project performance appraisals conducted during the controlling process of managing the project team.
Sitting in the local Java Jerry's, Herman picked up his conversation with Maya. Agile practices like iterative delivery sound okay, but I'm having a problem with the management style. I mean, 'egalitarian workplace' sounds like some liberal, socialist conspiracy. Maya almost bit her tongue when she saw the look of surprise on Herman's face. The guy was clearly a micro-manage r, b ut i f s Ce wanted to continue this conversation, she'd better find a gentler way to make hec points. Watching him hurry from the coffee house, Maya looked forward to talking. She had a feeling that thx conversations might be intense, but they'd also help her clarify her thinking about these concepts and keep he- sharp.
Participants are offered the opportunity of identifying characteristics they have in common Introduction Introductory questions open the general discussion topic in order to provide participants with an opportunity to reflect on past experiences and connect with the topic. The subsequent question is intended to foster conversation and interaction among participants, e.g., What has been your most important recent relation to SME networking processes Transition Transition questions move the conversation to the key questions that drive the analysis, serving as a logical link between introductory and key questions. Participants acquire awareness of how others view the topic Key Key questions drive the analysis and the focusing.
Based on his conversation with the executive, the CIO drafted the following problem statement We need to implement an optical scanning front end to eliminate keypunch input to the payroll HR system. The new system will reduce costs and improve quality. The CIO then convened a team consisting of a project leader and systems analyst from his organization, the manager of the department that had already implemented an imaging system, the marketing VP's assistant, and the manager of the keypunch effort.
Fortunately for Tina, one of the project managers she has worked for in the past saw what was happening. Because the administrative assistant was the one who had established relationships with the team and was in effect giving the orders, the team began treating her as the project manager instead of Tina. Tina's friend had a one-on-one coaching session with Tina about her management style and the importance of conversation and observation. Together they were able to get the project back on track.
Get into the habit of asking What's the bug number for that whenever issues come up. If they say there isn't one, end the conversation until the bug has a number. This may seem tyrannical, but it's in the project's best interest. The two minutes required to create a bug number are entirely worthwhile from a project-level perspective. It's fine for people to track things on their own if the issue has no impact on the build or the code base you don't want the bug system to be bogged down with bugs that are personal reminders or to-do list-type trivia. (Or if you allow it, make sure there is a specific bug type for this stuff, so it can be filtered out in reports and queries.)
Videoconferences generally require a higher level of rehearsal and testing than other communications tools, because the technology is relatively unfamiliar to most users. Videoconferences are normally limited to one or two remote sites because of the few seconds of lag time involved in getting information from one site to the other. Although that may seem an inconsequential period of time, those seconds make the difference between normal conversation across a conference table and a stilted conversation with accidental overlaps and miscues. Those awkward moments can be overcome through planning and coordination. The key in videoconferences is to identify gestures, cues, or handoffs that will facilitate more ordinary conversation. The other key is to encourage those who are not
Even when the technical challenges are overcome, the teleconference has the inherent difficulty of lacking face-to-face contact (as do most remote technologies). As such, parties in the conference should ask for clarification any time there are any misgivings about what is being said. The content of a conference call should be clearly outlined at the beginning of the call and should be identified with clear objectives for each content element. If the content requires support documentation, such documentation should be sent (via fax, e-mail, or posted mail) prior to the call, and there should be premeeting affirmation that the support documentation has been received. The call should be treated as a meeting, with a clear agenda, and with all conversation directed at the agenda. Because conference calls can get confusing in terms of who is speaking and any references they may make, any time the agenda is amended or superseded, there should be a clear definition of the objective of the...
Keep in mind that an effective meeting is one that has a specific purpose. We have all attended meetings that wandered around and at the end of the allotted time, nothing was accomplished. If you want people to attend your meetings, make them so action-packed and useful that no one wants to miss one. Clearly state the purpose of the meeting in the invitation. Attach or later forward a meeting agenda with clearly defined objectives and outcomes. Start and end the meeting on time, actively manage the meeting, move it along, and keep the conversation on topic.
On the application side, avoid the temptation to add new fields to FogBugz. Every month or so, somebody will come up with a great idea for a new field to put in the database. You get all kinds of clever ideas, for example, keeping track of the file where the bug was found keeping track of how often the bug is reproducible keeping track of how many times the bug occurred keeping track of which exact versions of which DLLs were installed on the machine where the bug happened. It's very important not to give in to these ideas. If you do, your new bug entry screen will end up with a thousand fields that you need to supply, and nobody will want to input bug reports any more. For the bug database to work, everybody needs to use it, and if entering bugs formally is too much work, people will go around the bug database. At that point, your ability to track what's going on goes out the window. When bugs are swapped by e-mail, hallway conversation, and cocktail napkin, you can't trust the...
Within a team there will often be differences in opinions. If you want to hear a heated discussion, put ten Visual Basic programmers in a room and start a conversation on the best coding standards for a Visual Basic project. Creating any standard will result in discussion and compromise.
Implication that he does not understand his business. He might ask why the PM wants to know. That's marketing information. What does it have to do with the project The PM needs to position the conversation so that the Marketing Director can understand that the PM would like to be able to make a judgment about whether he can produce the required value. Or, when asking management about their reasons for requesting the project, the PM needs to ensure that he is not misunderstood as believing that there is not good value in taking on the project. Perhaps some introduction such as I need to understand some things, because I have to build the product and I have to know what to build, and I also have to convince other people to do the right things. I would appreciate any information you can share, to allow me to do my job better.
In the storming stage, tendency is for the members to all at once set out to establish their boundaries. Territory is claimed stands are taken. Though technical on the surface, these interactions are really about establishing dominance or staking out territory. Sometimes the fights become more personal. Members attack each other's competence, sometimes in public, but more often in intensely private conversations in your office. They may also rail against the management for putting them on this team the project's schedule and budget are impossible, and so on.
Networking is the formal and informal interaction with others in an organization, industry or professional environment. It is a constructive way to understand political and interpersonal factors that will impact the effectiveness of various staffing management options. Human resources networking activities includc proactive correspondence, luncheon meetings, informal conversations including meetings and events, trade confcrcnccs, and symposia. Networking can be a useful technique at the beginning of a project. It can also be an effective way to enhance project management professional development during the project and after the project ends.
1 Never underestimate the value of a well-placed workspace. I learned much about what was going on above me in management from that location. It enabled me to have informal chats with all kinds of people who were looking for Chris and to innocently overhear important hallway conversations. The downside was that the big boss was right next door. Had it been a manager with control or micromanagement issues, there would be serious downsides to such a location.
For this and other reasons, the specification work should begin during the design phase. As prototypes are being made and ideas explored, small decisions start to fall out of the work, and rough-draft specification documents can begin (and should be marked as early drafts). They can be kept private for a while until there is enough description to be of value to more than one person. In conversations between project management, design, marketing, and programming, a slow but steady understanding grows about what the right design is, and the spec should trail those discussions. As the design process hits the point in time where there are only two major alternatives, the specification should have strong momentum behind it. With only two alternatives on the table, specifications can minimally include all of the common elements and engineering work required in both alternatives (e.g., a search engine that is needed for both designs), as well as a high-level listing of the remaining major...
In my years in the Windows division at Microsoft, I worked for Hillel Cooperman, perhaps the most passionate and dedicated manager I've ever had. I remember once coming into his office with a dilemma. My team was stuck on a complicated problem involving both engineering and political issues. We needed another organization to do important work for us, which they were unwilling to do. I had brainstormed with everyone involved, I had solicited opinions from other senior people, but I was still stuck. There didn't seem to be a reasonable solution, yet this was something critical to the project, and I knew giving in would be unacceptable. After explaining my situation, the conversation went something like this What haven't you tried yet I made the mistake of answering, I've tried everything. He just laughed at me. Everything How could you possibly have tried everything If you've tried everything, you'd have found a choice you feel comfortable with, which apparently you haven't yet. We...
When you're having a conversation with prospective project team members, your goal is to find out how they can help you complete the project and how you can help them achieve their goals so that you can create a win win situation. The STAR interview method is an approach that you can use to help the prospect identify experiences, and cut through some bunk that may slip into their recollections.
Finally, all meetings need an agenda. This is to communicate the goal of the meeting to the participants, and is usually set by the meeting organizer. It should probably not exceed one page, preferably one side only. The contents will be, at a minimum, the title, location, date and time of the meeting, participant list (anticipated), and a series of points detailing the topics of conversation.
As we step through the assessment activities, we'll also discuss best practices so that when you're ready to develop your operational security project plan, you'll have the information you need to develop a solid incident response plan. Before we head into the details, let's take a quick look at the history of incident response.This will give you a bit of perspective and it's a great (geeky) conversation starter at tech conventions and high school reunions.
Get All The Support And Guidance You Need To Be A Success With Conversation And Communication. This Book Is One Of The Most Valuable Resources In The World When It Comes To The Art Of Conversation And Communication.