Archive for the ‘Advocacy’ Category

Be a better blogger – Add a Summary Sentence

Adding a summary sentence to the top of a blog post helps a reader decide if they want to stay and read your post.

My team took a great course on writing for the web where we learned a number of tips and techniques to improve our blogs. I want to share some of what we learned so you can be a better blogger

The average user spends 10 seconds looking at a web page before they decide if they want to stay and read it. That means you have 10 seconds to convince them they want to read your post. Now having said that, not every post is intended for every reader. When I write a blog post about the Imagine Cup competition it is aimed at university and college students taking Computer Science or Engineering. Whereas this blog post is aimed at bloggers. You don’t need to hook all readers, just your intended audience.

The easiest way to tell someone in 10 seconds or less what is in your blog, is by adding a summary sentence. I find putting it in a different font size or color helps it stand out.

Don’t believe me? Test it out

Look at this blog post for 10 seconds. Do you know what you will learn if you take the time to read that blog in full? Was 10 seconds enough time for you to make a good decision as to whether you want to read that blog?

Now look at this one. A little intro paragraph at the beginning helps doesn’t it?

Now look at this one. See how the opening two lines give you enough information to decide if this blog is of interest to you?

Now look at the first sentence of the blog post you are reading right now, did that sentence catch your eye? Did it help you understand what you would learn by reading this post?

It doesn’t take long and your readers will appreciate it!

Want Your Presentation to Rock? Hook Your Audience Early!

Every day professors there is a lecture room with someone standing up front talking about Fourrier Transforms or looping algorithms. Whether it’s a class presentation,  a lunch and learn for fellow students, or a presentation on a co-op term, all of us are called upon to present from time to time. When we put together a presentation it can be tricky to deliver the information the audience needs in a way that will hold their attention. You want a presentation that will grab and hold their attention. Luckily there is a very easy 5 slide structure you can use in your slide decks to quickly get the audience invested in your presentation.

I really believe you have to get your audience hooked right from the beginning. Whether you are presenting at a conference, to a client, to your boss, or to co-workers. You want to make sure the audience understands what you will be talking about and why they should care right away! We all have limited time, so when I sit down to listen to someone else present I want to know right away what am I going to get out of this presentation.

The structure I use at the start of my decks is based on the principles in Beyond Bullet Points by Cliff Atkinson.

Let’s say I wanted to talk to a group of programmers about developing an application for a Windows Phone. A typical presentation might start out with a slide that shows a picture of a windows phone, then it might display a slide that lists the tools you need to download to start developing, then a slide listing the hardware and software requirements to use the tools, you have a few slides talking about the different types of phone applications you can build, then maybe you do a Hello World example, and you do various code examples and demos and finish up with talking about how to publish an app to the marketplace. Sound about right? That’s fine, but it could be so much better! All you need to do is put careful thought into the first 5 slides!

Slide 1 The Setting

The very first slide in your deck should give your audience the setting, telling them where we are right now. Think of it like a sort of one sentence status update, a state of the union. Ideally this setting should be expressed as a single sentence with a single image on the slide to reinforce it. For example

“The Windows Phone MarketPlace offers great opportunities to get noticed” and an image of someone who stands out in a crowd.

Other examples of setting statements

“SQL Server 2012 CTP3 has just been released”

“MVC is becoming a popular model for web development”

“All companies need accurate information to make decisions”

Slide 2 The Protagonist

The second slide should help the audience understand how they fit into this setting, so they can understand how your first statement is relevant to them. Again keep the slide simple, one sentence, one image!

“You know .NET, so you can code a windows phone application” with a picture of a happy programmer, or the .NET logo, get creative have fun with it.

Other examples

“We are currently running SQL Server 2005”

“Our team maintains 15 corporate websites”

“We have 45 databases at our company storing 61 TB worth of data”

Slide 3 The imbalance

This slide should give a sense of the conflict, the problem, it should start to make people feel like we need to do something. Stick with the one sentence, one image format.

“The Windows Phone Marketplace is an untapped opportunity” with a picture of Monty Burns from the Simpsons rubbing his hands together with glee (like I said you can have fun with the images)

Other examples

“We need the business intelligence features in SQL Server 2012”

“None of our websites share code”

“There is wealth of information in our data that can help our company succeed”

Slide 4 The balance

This slide should tell the audience the desired outcome, where we want to be in a week, a month, a year, or even in an hour when this presentation is completed. Oh and guess what format the slide should be…yup one sentence, one image. By the way lets be clear, I do mean an actual sentence, with punctuation and everything, a bullet point is not a sentence.

“We want to develop windows phone applications” with an image of a windows phone showing the company logo on a tile

Other examples

“We need to upgrade to SQL Server 2012”

“We want our code to be re-usable across websites”

“We can get information about trends and patterns from our company data to plan company strategy”

Slide 5 The solution

Now it’s time to reveal what you will really be talking about in your slide deck, the solution, how will we get from where we are now to where we want to be, from the imbalance to the balance!

“You can develop a phone application” with an image of a finger pointing at the audience.

Other examples

“There is an upgrade path from SQL 2005 to 2012”

“MVC will allow us to re-use more of our code”

“SQL Server Analysis Services cubes will help us report on trends in our data”

Put it all together and it comes out like this

The Windows Phone Marketplace offers great opportunities to get noticed. You know .NET, so you can code a windows phone application. The Windows Phone Marketplace is an untapped opportunity. We want to develop windows phone applications. You can develop a phone application

or

All companies need accurate information to make decisions. We have 45 databases at our company storing 61 TB worth of data. There is wealth of information in our data that can help our company succeed. We can get information about trends and patterns from our company data to plan company strategy. SQL Server Analysis Services cubes will help us report on trends in our data

If you were in the audience after these slides, would you know what was coming next? that’s the whole point, now I understand what you’ll be covering, how I am affected, and why we are having this discussion.

Just 5 slides and you are well on your way to a great presentation. An interesting aspect of these first 5 slides: they don’t take long to cover in your audience. I probably average about 30 seconds a slide on these. So they add very little to your overall presentation time yet they go such a long way towards setting the stage for the rest of your presentation. So next time you are firing up PowerPoint, before you jump straight into the content, take a minute to think about those first 5 slides. By the way, if you go back and read the first 5 sentences of this blog post…you’ll see this format can work for introductions to blogs as well Smile

 

This blog is also posted on the Canadian Solution Developer

Conference or Course? Where Should I Spend my Training Budget?

I started work in the era of Stephen Covey and the ‘7 Habits of Highly Effective People’ craze. Heck I was even sent on a 7 Habits course and given a 7 habits daytimer! One of the 7 habits was to ‘Sharpen the Saw’ which amounts to the importance of spending time improving yourself and learning. The IT world changes so fast! You have to keep learning to keep up! The smartest employers recognize this and invest in training for their employees.

I am busy getting ready for TechDays Canada, and also preparing to present to Microsoft Certified Trainers (MCT) at the MCT Summit. I spent 10 years teaching Microsoft courses and I have presented and attended numerous conferences over the years. I know that most of us are faced with limited budgets and time for training. You have to make the most out of your training time! Sometimes you are forced to choose between attending a conference and taking a course. I want to give you an honest comparison of the two options so you can make the best decision!

Criteria

Conference


Course

Cost Tend to be $200-$400 a day, but often have significant early bird discounts or promo codes. Tip: Decide and book early! Tend to be $300-$500 a day,
Tip: Check websites or call and ask the sales staff if there are any promotions and discounts.
Travel The bigger the conference the more likely you are to need to travel.Many user groups will organize events locally, for example TechDays may be in Montreal, Toronto, and Vancouver this year, but we are sponsoring locally organized events like DevTeach in Ottawa, Prairie DevCon in Winnipeg and Calgary. The more specific the course and the more obscure the topic the more likely you are to need to travel.If you are just looking for the basic how to code .NET, how to use SharePoint you should be able to find that nearby.
The Wow factor Imagine if you had attended Build and received the free slates with Windows 8 installed! Keynotes with big names and announcements! Product booths where you can play with the newest tech toys! The wow factor in a course comes from your desire to learn what it taught in that course and having those ‘aha’ moments when you finally get it!
Topic Breadth Conferences will cover a broader array of topics than a course Courses will cover a lot of material on one specific topic
Topic Depth Due to the length of sessions, you rarely get great depth in a conference, but keep an eye out for pre and post-conference sessions that frequently offer deeper dives for an extra fee Courses will go into much more depth on a specific topic
Current technology Conferences are generally the best places to learn about the latest and greatest tools and features Because it takes time to develop courseware, and you need a certain momentum in the market with a product to sell a course, courses tend to be one version behind the current release. But occasionally you can find a one day new features course or a seminar on a new release.
Immediate help with your current role If you pick the right conference and attend the right sessions, you will definitely walk away with something you can use the moment you get back to work. When we pick sessions for TechDays that is actually one of our criteria. If a conference has a partner expo that can be a goldmine as well, those partners have some great tools and resources, not just t-shirts and pens! Check the conference website and look at session lists to make sure this is the right conference for you. If you have selected the right course, you should be able to use what you learn right away.  Read the course outline to make sure this course is going to cover topics that apply to you. For example there are a dozen SQL Server courses, do you want to learn how to write reports with Reporting Services? or do you want to master T-SQL? or do you want to learn how to do backups? Each skill is in a different course. Even if you have already worked with the product for a while, taking a course can be worthwhile to pick up a few new tricks! But if you have 3 years experience with the product, you shouldn’t expect to get as much from the course as someone with 2 months experience with the product.
Help with your career long-term If you are looking to move into a senior technical role, you want a conference that talks about design, architecture, application lifecycle methodologies like Agile (hint: TechDays Architecture track)If you are looking to move into a management role you may want to complement those design and ALM skills with a conference aimed at managers and project management. If you are looking for a senior technical role, you want to try and find a course that talks about design, Application Lifecycle Methodologies, and architecture. I’ll be honest, these courses are tough to find, so if you find one that works for you, re-arrange your schedule and take it!If you are looking to get into a management role, there are lots of courses out there to teach you project management skills.
Asking Questions Conferences will have a Q&A at the end of each session, and a good conference will have some sort of open area where you can talk to speakers (some sort of Ask The Experts zone) but you may have to miss a session to find time to talk to your expert. However you can usually get email addresses for the speakers to follow up with them outside the conference. You will have much more opportunity to ask an instructor questions than a speaker at a conference. It’s simply a question of time and the number of people learning. It’s easier to take questions over a week across 12 students than when you are presenting a session to 150.
Hands On Time with Product More conferences are discovering the value in giving attendees hands on time with a product. For example we have Instructor Led Labs at TechDays where you get to actually walk through an exercise on your laptop during the session. But not all conferences offer hands on product time. Most courses will include lab exercises so you get a chance to reinforce what you learn.
Networking Conferences have more people attending and are generally better for networking. They often have social events, or luncheons where you can talk to other attendees.
Keep an eye out for opportunities to network with the speakers as well at Product booths and Ask The Expert areas
You meet a smaller group on a course, but that smaller group is interested in the exact same topics as you, so you are more likely to find a kindred spirit who has faced the same challenges as you, and don’t forget the instructor is a good contact as well. If you ask nicely, many instructors are willing to share their contact information, as long as you promise not to ask them to debug your code, or architect your next solution for them by email.

THE WINNER IS…

It depends! You knew that was coming didn’t you? Hopefully I’ve given you a few things to consider if you have to choose. If you just started on a new team and have never used the tool, maybe this year you need a course, but if you are simply looking to grow in your current role, get excited about your job again by picking up some new tips and geeking out with some fellow fans of Big Bang Theory. Join us at Techdays! I’ll see you there!

This blog is also posed on the Canadian Developer Connection

Why do IT Projects Fail?

I read an interesting article in this morning’s Ottawa Citizen. It says the auditor general has stated the government is mismanaging a number of IT projects. The auditor general’s office found a history of cost overruns and delays and of not delivering on the project’s planned purpose. There are a myriad of reasons that can cause a project to run over budget or miss deadlines. I’d like to hone in one of that one specific point from the article “Not delivering on the project’s planned purpose.”

This one hits close to home for me because for the past few years I was training not just developers but also IT business analysts. A business analyst gathers the requirements for an IT system. A systems analyst on the other hand determines the specifications for an IT system. What’s the difference?

Requirements describe WHAT the user needs from the system. For example, the user needs to be able to know who reported a bug and needs to be able to track the progress of the bug they reported.

Specifications describe HOW the system will meet that need. For example, there will be a SQLServer database and a User table with a ReportedBy field of type VARCHAR, there will be a mobile application which will allow users to view the status of their bugs written using Silverlight and a web service.

Some projects have dedicated business analysts who will gather the requirements and hand them off to the technical team. On other projects members of the technical team are asked to gather the requirements, Sometimes, requirements gathering is skipped and we just start building because “we know what the user needs” You can be successful gathering requirements with business analysts or technical team members but you should never skip requirements gathering because you think you know what the user needs. Even in the agile methodologies the user is the one who drives the content in the sprints.

With our technical skills we are very good at building solutions to meet a specific need or requirement. I have been blown away over and over again with the ability of programmers and system architects to come up with creative ways to meet users needs even when faced with technical limitations. But, if the users needs aren’t well understood in the first place you are headed for trouble.

Indulge me for a moment as I relate a short story from my own work life. I was managing a few programmers and was asked to build a small application for another team to use internally. I sat down with the team lead who wanted the system for about an hour to get a feel for what they were after. Then I walked away, sat down with my team and we designed a solution to meet their needs. That first meeting was the only meeting I had with the other team. We were on a project that was already behind schedule and over budget so there was a lot of pressure to get this application out the door. Since it was an internal application there was no requirement from management for lengthy documentation or sign off. With a lot of long hours and creative programming we turned around the application in two weeks! We were patting ourselves on the back for a job well done, especially with the time constraints! We walked into a meeting with our customers (the other team) to show them this wonderful new application we had built for them. Within 5 minutes it was clear that although our application worked fine, it did not meet the other team’s needs! They got angry because the system didn’t meet their needs. We got angry because we had just killed ourselves for two weeks getting this completely functional solution built and out the door. The result was increased tension and anger on a project that was already under stress and a solution that didn’t actually help the other team’s productivity. Why did it happen? Because we didn’t fully understand the requirements!

I can’t teach you how to correctly gather requirements in one blog post, I can tell you gathering requirements is a critical success factor for any project and requirements gathering is the theme for today’s My 5

My 5 tips for successful requirements gathering

  1. Your requirements will be wrong – No matter how much time you spend on requirements, no matter how many users you talk to, and how many meetings you hold, you cannot get the requirements 100% correct. That doesn’t mean you should just skip requirements gathering because the requirements will be wrong, it just means you need to accept the fact you can’t get it 100% right.
  2. When gathering requirements your goal is to find as many mistakes in the requirements as you can with the time you have – Since you can’t get requirements 100% correct, you want to get as close as you can to 100% with the time you have. How do you find mistakes in the requirements? See Number 3.
  3. Engage the users early and often – Users will forget to tell you something in that first meeting, or a different user will be aware of a requirement that another user will miss. Engaging different users, and following up with emails, phone calls or additional meetings increases your chances of finding mistakes or gaps in the requirements
  4. Get requirements signed off before you start testing – It is not unusual for a project to start development when the requirements are still in flux, but how can you test to see if requirements are met if you haven’t agreed on the requirements yet?
  5. Document in one place only – Since the requirements are wrong, you know you will have to update them as you find the mistakes and gaps. Get creative in how you document your requirements. If you find yourself doing a cut and paste from one requirements document to another, ask yourself how can I document this in one place so that *when* it changes, I only have to update the requirement in a single place.

For more information about requirements gathering, I suggest you check out The International Institute of Business Analysis (IIBA). They organize conferences on requirements gathering, and they even have a business analysis certification based on the information in the Business Analysis Book of Knowledge (BABOK) which is chock full of best practices for gathering requirements. Some of the tips in todays My 5 come from material prepared by Noble Inc.

This blog is also posted to Canadian Solution Developer

How to Make Your Code Demos Rock!

imageDo you present at user groups, or conferences? Maybe you have to walk through your code at team meetings. Regardless, there are a number of little things you can do to make your code demonstrations more effective. Whether you are working with SQL Server Management Studio, Visual Studio, or the Command Window, it is worth taking a little time to learn a few best practices. That’s why I co-presented a session entitled “Creating Captivating Code” with developer MCT, Christopher Harrison (@geektrainer) at the “MCT Third Thursday“ April 21st.  If you are an MCT, you can visit the MCT Summit site and see the recorded session. For those of you who are not MCTs, maybe you want to become one (but that’s a blog for another day,) meanwhile, I’ll share a few tips and tricks here.

The first step is to take some time to learn how to make the most of the tools themselves. For example, if you are doing a demonstration in  Visual Studio, choose Tools | Options from the menu and explore!  You can add or remove line numbers, change the font size, or even the tab settings.  Learning how to use the tool features to make your code appear more clearly will make your demonstrations more effective and can even make you look smarter Smile! Don’t believe me? Next time you are showing someone your code in Visual Studio, put your cursor in the code window and try <ALT><SHIFT><ENTER>. I promise you, your co-worker will look at you impressed and say “Hey, that’s cool! How did you do that?” (by the way to exit this mode use <ALT><U>) Like that trick? There is a great session from TechDays called Visual Studio Tips 2010 and Tricks you can watch to learn more. In SQL Server Management Studio, go to the menu and choose Tools | Options | Environment | Fonts and Colors, choose Selected Text Item and set Background to yellow, and Foreground to black. Now when you highlight part of a SQL command or stored procedure it will jump out at you (no 3D glasses required.) Working in the Command Window? Right click at the top of the Command Window and choose Properties | Font | Size to change the size of the font (I like 12X16.)

How you write your code affects code demonstrations too. Formatting counts! Indent your If statements and loops, use meaningful variable names, make keywords uppercase in your SQL commands. This makes your code easier to read and consequently easier to understand. Keep your methods short, I don’t need to see the code that declares the connection string when you are trying to show me a LINQ query. If you want to write the code from beginning to end so you can show all the steps required, consider refactoring. For example, if you start your demonstration by creating and opening a connection, refactor that code into a method called OpenConnection and call the method, then go on to write your query. This way when you are explaining the query all eyes are on the query, exactly where you want them!

My 5

5 Tricks to improve demonstrations in different tools

  1. For all your demonstrations – Install and use ZoomIt or something equivalent. With Zoomit, you can zoom in when the text or image is too small to see. In particular, Zoomit is great for property windows, Explorer windows and execution plans.
  2. SQL Server Management Studio – Change the Font Size for the Text Editor, Grid Results, and Text Results (Tools Options | Environment | Fonts and Colors)
  3. Visual Studio – Change the Font Size for the code editor window (Tools Options | Environment | Fonts and Colors)
  4. Command Window – Change the Screen Background to White and the Screen Text to Black (Properties | Colors)
  5. Windows Phone 7 – Clean your fingernails. It sounds nitpicky but seeing an enlarged view of dirty fingernails on the projector is actually distracting me from the cool stuff you are trying to show me!

One of the great debates (aside from VB vs C# but that is a discussion for another day) is whether code demos should be kept simple to just illustrate the concept, or more complicated so they better reflect the real world. I would be curious to know what you think both from a presenter and audience perspective. Should code demonstrations be Simple or Real World?