Lessons learned web briefing v1.0 3rd April 2012 APM Web Briefing - Lessons Learned Introduction In project management we rarely seem to apply Project Lessons Learned. Projects vary in terms of purpose, cost, magnitude and the timelines involved. Yet, they all have common features and the lessons learned from one project can easily be incorporated in another, circumstances permitting. Some of the experience thus gleaned is revealed below. This is by no means an extensive list of all the project lessons learned, but a few of the most relevant, are stated herewith: The success of a project is largely dependent on the skills and strengths of the people involved. Therefore, a project needs to have a dedicated, talented set of individuals working towards a common goal. Together with leadership skills, the project manager needs to be aware of the strengths and weaknesses of his/her staff, so that the talents are harnessed and the shortfalls downplayed for the benefit of the project. A champion team and a team of champions are indeed different. The former would lead to a successful project whilst the latter would yield to a conflict of egos, each chasing an individual goal. It pays to know who the decision makers are. Such individuals may not always be readily visible, but they will be calling the shots, so developing a strong line of communication with such individuals will reap benefits in the long run. If you have the knowledge and experience to make a decision, then you should go ahead and so, without expecting top managers to spoon feed you at every turn. Procrastination does not work. After assimilating the relevant information, decisions need to be made. Wrong decisions can be salvaged, if discovered early; but right decisions cannot be postponed. So, Carpe Diem, (seize the day), as advocated by the popular maxim. When things go wrong, as they invariably will; excuses will not work. Find an alternative course of action or remedial propositions instead. Allocating blame only causes dissention and hostility, searching for solutions will bring the team together. Be pro- active in your approach. Reactivity is just not good enough. Be open to change. Sometimes, you may find that the things you knew along may not be correct at this given time, under these specific conditions. Know what resources are available.
Presenting Lessons I've Learned. If you decide to take the leap into presenting. If you use a template provided with Powerpoint or Keynote. We need to go into post-project reviews knowing what lessons learned questions to ask to make the information valuable for people on future projects. Project Management: Challenges & Lessons Learned Joseph Amalraj Christine Hernani Kelly Ladouceur Aparna Verma BUEC 663 Dr. Joseph Doucet Friday February 9, 2007. Not just those under your purview but those which are at the discretion of other teams. Sometimes, others may be happy to help. After all, the favor bank concept which is colloquially referred to as the 'you scratch my back and I will scratch yours' philosophy, is apparent in the business world too. Paperwork and documentation are necessary for reporting purposes. But when making decisions, placing too much reliance on data which may have changed within a surprisingly short timeframe pays few dividends, especially in an unpredictable environment. Know your customer and know the objectives of the project at hand. If any significant changes need to be made, do so, but remember you need to consult the customer first. Respect your leader and his/her decisions. Sometimes, you may not agree with these. Voice your objections, especially if they are reasonable. But once an action has been decided upon, even if it is contrary to your idea of what should have been done, support it, and try to make it a success. Take account of all the known facts. Try to make sense of it, but don't blindly force- fit scenarios into a pre- established mould. Such scenarios may have been right before, and will, in all likelihood, be right once again, but maybe just not in this case. Do not be afraid of taking calculated risks. After all, as the adage goes, a ship is safe in the harbor, but that is not what ships were built for. When things go wrong, know who you can turn to for help. Always disclose information to those, who will need it. This is not the time or place for obtaining an edge over another by keeping crucial data close to your chest. People, who know what is expected of them and have the means of doing so, will play a pivotal role in making the project a success. Use modern technology and time tested management skills to your advantage. Good communication is that which will stop mistakes from becoming failures. Mistakes happen and recovery is always possible. But failure is a dead- end street. Do not blindly rush into decisions. Careful thought needs to be given to the circumstances at hand prior to engaging in decision making. This will save time in the long run by minimizing the need to redo work. Repetitive mistakes are the best avoided. Project lessons learned should be documented so that future team leaders can make use of the learning experience of others in order to avoid the same pitfalls themselves. Jay Fields' Thoughts: Presenting Lessons I've Learned. Up until a few years ago I'd never done any type of public speaking. I'm outspoken among friends, but generally shy around strangers. However, some opportunities presented themselves and I decided to take the leap into the world of presenting. I thought it might be helpful to document some lessons I've learned. If you decide to take the leap into presenting, I hope these ideas make your journey a bit easier than mine. Get Help - I took a class at Speakeasy (NYC). The class that I took forced me to stand in front of a small group of strangers, present on any topic I liked, and have the entire thing recorded. I learned about things that I was doing wrong, but I also got to see what mistakes the other people in the class were making. It was the single largest thing that improved my public speaking. Practice - the last public talk I gave was at QCon SF 2. In the weeks leading up to that talk I rehearsed the presentation at least 2. There's so many reasons why a presentation can go wrong, so you'll want to make sure you have the content down cold. You'll lose the audience's trust if at any time you look as though you don't have the content down 1. Don't Script Jokes - at QCon London 2. I was feeling nervous and chatting with Jim Webber. So I opened with the joke. But, it didn't come out smooth or well- timed, it came out dry and forced. No one laughed, and I got to start out my presentation with awkward silence. If you're naturally funny, it's fine to improv a joke in the middle of the presentation; otherwise, I suggest sticking to the content. Know Your Audience - Audience's will react to your content in different ways based on several factors, it's important to consider these factors when putting together your content. For example, a local Rails User Group may laugh at your joke about DBAs. However, at QCon there are likely to be DBAs, CTOs, and other audience members who may not find your DBA humor amusing. It's also valuable to consider language barriers. In Europe, where my audiences often very mixed, jokes never seemed to amuse the audience in my talks or any that I attended. Maybe, the humor didn't translate well, or maybe I was moving too quickly. Either way, I made a mental note to stick to the content when my audience was likely to speak English as a second language. Look Natural - At Speakeasy I learned that . It's extremely uncomfortable and feels unnatural to me, but I have the recorded video to show that I'm wrong. The problem is, if you are always waiving your arms around, or hiding them behind your back, you distract the audience. That's not to say you should never move your arms, but do it less often. I tend to point or gesture way too often, so whenever I notice that I am, I just naturally put my arms down and focus on doing that for a bit. Face Forward - When you turn your back on the audience, you lose them. Especially if you are talking with your back to them. Instead, take small, backward steps and always face the entire audience. Pictures - pictures are really the way to go. If you put text on the screen, people will read the text and tune you out. Some presenters are amazing enough that they get away with no slides at all. I don't suggest starting there. Technical conference- goers are used to slides. However, you can stick to pictures for your slides. If you have pictures that support your ideas, you can have slides while still forcing the audience to pay attention to you for content delivery. Short Text - If you must use text, don't use sentences, paragraphs, definitions, or anything else lengthy. A few words, as little as possible is the only way to go. If the audience is reading, they aren't listening to you. No Bullets - If you must you text, avoid bullets. Instead, show one line at a time and hide or shade the other lines. Code Is Acceptable - Some ideas are more easily expressed with a snippet of code. Don't avoid code when code is the best choice. Instead, when you bring the code up, give the audience 3. Just remember, as long as the code is on the screen, there will be people reading, and not paying attention to you. No Distractions - Distractions can ruin a presentation. Excessive transitions, morphing text, blinking text, etc all take away from the message that you are trying to express. I remember seeing a Flex presentation at Rails. Conf where the presenters showed their Flex Twitter Client. It was really pretty, and kept popping up tweets from conference attendees. Putting it up was awesome, leaving it up was the worst possible choice. I can't remember anything they said after they put up the application. I tuned them out for the remainder of the talk, and read all the tweets that kept popping up. I didn't mean to, but I was drawn to the shiny objects. After the talk I asked a few friends if the presentation was any good. They had no idea, we were all entranced by the twitter client. Start Small, Build Up - My wife is the first to hear (suffer) though any presentation that I put together. I practice it a few times, then present it to her, then practice a few more times, then move on to a slightly larger venue. A User Group or some peers at work are good audiences for a new talk. After you present to 1. Be Original - If you use a template provided with Powerpoint or Keynote, it's likely that someone else at the conference will be using the same template. Be Yourself - In my presentations I almost always swear and make some kind of sarcastic remark. That's how I act among friends and when I act like myself in presentations people tend to accept that what I'm saying is what I believe, not what I'm trying to pitch. Record Coding - Don't live code unless you've practiced it 1. Justin Gehtland. Okay, I'm (sort- of) kidding about having to be Justin. However, the reality is that live coding is really, really hard. Often, you can express the same thing with a recorded coding session and there's little to no chance that things will go wrong. Justin has acting, teaching, and presentation training. He's also ridiculously smart. Those things combined mean he can carry a live coding session even when things go very wrong. If you have the same background, go for it. Otherwise, stick with the, much more likely to succeed, recorded coding session. Questions - Pause for questions a few times during your presentation. It allows you to give color on ideas that you may not have clearly expressed. It also gives the audience the chance to see that you really know what you are talking about. For me, it also helps me relax and provide conversation, instead of simply lecturing. Breathe - You know your content, the audience doesn't. Chances are you are going too fast. The simple rule of thumb is, the audience is always at least 5 seconds behind whatever you are saying. If you take the time to breathe or take a sip of water, you give them the opportunity to catch up. Relax - The best presentation ratings I've ever gotten were when I gave a presentation entirely hungover. I thought I was going to be terrible. But, I was too hungover to be nervous, and I gave a straightforward, natural presentation on the ideas. I'm not advocating that you get drunk the night before your presentation, but do take steps to relax, if you know how. For me, I like to have friends in the audience, a drink about an hour before the presentation and a drink right after. It's my ritual and it helps ensure that I'm as relaxed as possible. Almost everything I learned I got from Neal Ford, Jim Webber, and Dan North. Thanks for the ideas, gentlemen. If I left anything out, it would be cool to see additional lessons that you've learned throughout the years. Update: Steve Vinoski said.. I'd add the following: Always repeat any questions asked of you before answering them. This is important not only for the audience in front of you, but also especially for any audience viewing a recorded session at a later time. Don't be afraid to answer . The audience would rather hear honesty than some made- up BS. Presumably you possess specialized knowledge or wisdom, otherwise you wouldn't be up there speaking, but that doesn't mean you know everything, and frankly the audience doesn't expect you to. Ask the audience questions. This helps keep them engaged. Remember, your talk is really more about them than it is about you, so gauging the audience and adjusting accordingly can help maximize the value of your message to them. Should you encounter an audience member who wants to challenge you and argue with you, just politely decline to engage by saying you'll be happy to discuss the issue with them after the talk. Back- and- forth arguments with an audience member lose and annoy most of the rest of the audience almost immediately, and since you're probably not repeating every statement the arguer makes, anyone watching a recording of the argument hears only half of it and you lose them immediately. Above all, respect your audience and they'll respect you. Except in extremely unusual circumstances, they want you to succeed because that way they'll get the most out of your talk. If you're a new or nervous speaker, keeping that in mind can help put you at ease.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
January 2017
Categories |