Tag Archives: Planning

Office Worker Essentials

, ,

A century ago the majority of people were employed in manual labor: either on a farm or in industry. A small minority worked as professionals. They were the early knowledge workers. Their primary tools were the pen and paper. How times have changed. Today every knowledge worker has a myriad of tools at their disposal and they are expected to master them.

This is the first article in the series on Starting in a Software Development Career.

You have to work with at least two office tools: email and calendar. First things first: resist the temptation to use your office email for personal messages. The company owns, operates, or at least pays for the email system. It should be used only for company business. Find an email provider that you like (Google Mail, Yahoo!, iCloud, Outlook.com, etc.) and sign up for a free account (if you haven’t already done so). Use this account for your personal messages. Even though you will end up with two email boxes and two calendars, you are still better off keeping company business and your personal business separate. This applies to you if the other email is your school or college email, not work.

Setup filters for your incoming email that tag (and sort) your mail. This allows you to focus on the more important messages (either because you tag the important ones, or filter out the less important ones). Setup shortcuts, or just learn the ones your email system already has, that allow you to move the messages quickly into your email archive or the trash bin. Use filters to retrieve tagged messages from the message archive.

A good email habit to get into is to check your messages just a few times a day, only when you are ready to process them. Processing your messages means that you look at the message, and decide on the spot what to do about it. If you can complete the work required by the email in less than 30 seconds, then do it right then. If you think that it will take longer, then schedule time on your calendar to get the work completed. If you need to keep it for reference, then tag it and archive it. Otherwise, delete it. 1

Keep your calendar current with all your scheduled activities. Attempting to keep meetings and appointments in your head will sooner or later result in missing one. Add calendar entries that reserve time for doing your work to ensure that nobody schedules you for something else when you need to focus. Most calendaring apps allow you to color code your calendar to see at a glance what your day or week looks like. Pick 4 to 6 categories, assign colors to them, and color your calendar entries accordingly. You’ll be surprised how much faster you will grasp what your day or week looks like.

As you attend meetings and talk to your colleagues have a notebook so that you can write things down. You will come across well organized and dependable as a result. People will trust you more if they know that they can count on your listening to what they are saying, taking notes, and following up on requests or action items.

For your engineering work, keep a separate engineering notebook where you record your engineering thoughts, sketches, theories, and observations. For both of these uses there are good electronic notebooks for laptops and tablets. If you are not comfortable having everything online or you can’t quite feel that the electronic pad can capture everything that you want to sketch, then you may still want to have a paper notebook. Always date your notes; it is a practical habit to adopt to ensure that you can also find your ideas if at least you vaguely remember when you thought of them.

There is a good chance that your workplace will also have a corporate wiki for collaboration and knowledge management. You need to learn how to use one and get used to working with it regularly. Wikis are a great way to collaborate with your colleagues even if they are in the same office with you (because writing will clarify your thinking), but especially across time (asynchronously) and geography (especially long distances). For more on how to use a wiki see: What Makes a Good Wiki and What Makes a Good Wiki Page. In addition to the collaborative editing aspect of every wiki page, the comments and highlighting on every page are a useful collaboration tool, too.

Another element of every person’s life (both personal and work) is online chat, also known as messaging. In the work setting chat has been elevated from idle diversion to the status of a useful productivity tool. Chat channels are used for connecting people around a common projects, interests, or locations. To be a successful chat user, you must learn how to manage your chat-driven interruptions. There are times when you may not want to be interrupted by chat messages. Let your team know this in advance. Tell them when you are available, so that they can count on you. Most messages do not require immediate attention. A workable strategy is to let people know that if it’s urgent, they should use some other method to contact you, like a phone call, etc.

That takes us to one of the oldest office tools: the telephone. For most software developers the telephone lives on as a device for conference calls, though even in that aspect is getting replaced by online voice and video calls or tools like GotoMeeting and join.me. Since these days you are not likely to get a lot of voice messages, I recommend that you check your messages before you leave for the day; you never know, it might be from somebody important.

In almost every knowledge worker role, certainly most roles in software development, from time-to-time you are expected to prepare and deliver presentations. Learn how to use a presentation software, be it PowerPoint, Keynote, Slides, or anything else that your workplace standardizes on. You need to know at least how to: (1) edit and create presentations, (2) put the presentation software in full-screen presentation mode from the beginning and from the current slide, and (3) pick the appropriate screen for displaying your presentation. Practice these skills for a few minutes every week until your learn them, or at least practice it before you present. Make sure that you practice with the equipment that you will present with. Since there is a good chance that you don’t present a lot, during those few occasions when you do, you will have a lot of eyes on you as you fumble with your computer, projector, or the cables that connect them together.

Plan your work and work your plan. It is an old adage and it still holds true. Avoid the desire to make a perfect plan. Your goal should be to make a plan that can guide your work. A good plan will warn you when you are getting off track. When you cannot make a plan for the work, that’s a sign that at this time you may not know enough to do that work. This can be either an opportunity or a problem: if you realize this early, you may still be able to learn what you need to know, but if you find out late that you are lacking critical knowledge, then you might not be able to complete your work on-time. Then you have to ask for help. For details on how to plan, see my earlier post: Brief Introduction to Personal Planning.

Whenever you accept to do any work, even as simple as a task, part of that work is to report the completion of that work to whomever gave it to you. Or, if the work takes more than a day, then it is a good idea to agree ahead of time how often you are expected to report on the status of the work. If it takes more than two days to do, then identify smaller chunks of work that you can complete in a day or half-a-day. As you work through the first few tasks, you will have a better idea about how the work is going. And, you’ll be able to report on your progress.

Lastly, learn to touch-type and dictate. Most software developers spend a great deal of their time in front of the keyboard. Thus it is a very useful skill to learn how to type without having to hunt and peck for every key on the keyboard. Typing at a respectable 30 to 50 words-per-minute is within everybody’s reach.

Dictation used to be a skill reserved for top executives. Today voice recognition is built into almost every mobile phone and computer. As a result, it is possible to dictate to the computer what in the past you would’ve had to type. However, dictation is a skill that needs to be learned. Learn how to do this and you will save yourself a great deal of typing. (As you may have guessed, I dictated part of this post.)

Look through the above list, pick something that you feel you should do next and get going on it. You will enjoy getting more effective, more productive, and you might also have some fun along the way.

____

  1. For more on processing your messages, see *Getting Things Done*, by David Allen.

Brief Introduction to Personal Planning

As a knowledge worker, you live in a world where a continuous stream of commitments are made and accepted ’round the clock. To succeed in this world, you must learn to make commitments and keep commitments. Since commitments that rest on a plan are more likely to be kept, you must learn to make plans quickly for your work and then carry out those plans effectively.

Maybe you have encountered the following situations: your client has to remind you that you haven’t provided the white paper that you promised over two weeks ago; you seem to be the last person to finish your work for the release and the rest of your team starts to notice it; or your presentation for the team meeting is not done until late into the evening the night before the presentation. If you have been part of the business world for a while then you know that commitments will be made–one way or another–so not making commitments is not a viable option.

The situations mentioned earlier often happen because you make commitments without thinking through and planning out that commitment. Sometimes you make commitments under pressure, direct or indirect, that influences you in ways that later come back to haunt. Or it could also be that you, like many people, probably feel that planning is arduous and unrewarding. It doesn’t have to be that way. With a little practice you can learn to make plans for yourself quickly enough to productively participate in the commitment making process. Armed with a bit of self-knowledge and a few handy practices you will be on your way to make planning fun and make commitments that you can keep.

Effective planning demands of you–and knowledge workers in general–to think through the information do you owe to the people that you work with. Specifically:

  1. To whom do you owe information?
  2. In what form do you owe that information?
  3. Under what timeframe do you owe that information?

You must make a plan to deliver that information successfully to the people that need it from you. This information represents your commitment and it might be in the form of written pages, diagrams, presentations, software code, or any other piece of work product. This is what you make, this is the output of your work. As a knowledge worker, your widgets are processed information: you take in one kind of information, think through it, analyze it, synthesize it, and produce a different kind of information ready for the next person to consume.

For you to do your job well, you must plan the processing of information into work products that your consumers need. Successful planning involves performing the following activities:

1. Identify Tasks. Identify and list out each piece of finished work that you are expected to complete. If the piece of work is bigger than what you can picture in front of you, then you have to figure out how to take it apart. You proceed on taking it apart until you can picture each new part in front of you. This easily can be the hardest part of the planning work in particular, and knowledge work in general.

2. Order Tasks. Arrange the work in the order in which you need to get it completed. The beauty of doing a plan for yourself is that there are no complicated dependencies. You simply list the work items in the order in which they can be done. If at any time you find that you got the order wrong, just reorder the list.

3. Estimate Size. For each piece of work that you identified, figure out the size of that work. The size can take many forms: How many problems do you have to solve? How many features and sub-features do you have to build? How many customers do you have to call? How many pages do you have to write? How many slides do you have to create? Remember that you will have to keep dividing things up until the pieces of work become small enough that you can wrap your mind around them.

4. Estimate Productivity. For each kind of work that you have identified, decide on a productivity metric that you can apply to doing that work. Search your past experience for anything similar. If you have never had a similar experience, then envision what would it take to do this and use your best judgement to establish a productivity measure for the work standing in front of you. Here you might consider the following: the number of pages that you can write per hour, the number of drawings that you can produce per hour, the number of defects that you can fix per hour, the number of problems that you can identify per hour, and so on.

If you estimate that you cannot get one item done per hour, then use the reverse measure and identify how many hours does it take to create one, for example how many hours would it take to draw a diagram.

5. Calculate Durations. For each piece of work apply the productivity measure to the size of the work that you estimated in the previous step, and compute how long will it take complete that part of work. This should be simple math: if you identified that your white paper is going be 6 pages, and you expect to write the paper at a rate of 2 pages per hour, then you are estimating that completing the white paper will take 3 hours.

This is where you might also want to think of some other tasks pertaining to the part of the work that may have eluded you originally: Should you have somebody review the paper? What happens if they find something in the paper which will require of you to rewrite the introduction? If you feel that these are likely scenarios, then include tasks for these in your plan.

6. Estimate Available Time. Look at your calendar and consider how much time you have available to complete this work. This involves thinking through all other commitments that you have already made, since those will also take up your time. Make sure to account for any small and large things that take up your time: preparing for a board meeting and preparing for a surprise birthday party for your friend could be equally time consuming and thus leaving you precious little time left to spend on the new commitment that you are about to make.

7. Calculate Schedule. Fill in your available time found in step 5 with the tasks durations that you computed in step 4. This will give you a schedule that can serve as the basis of your commitment.

8. Track and Improve. Once you start working on the tasks, track your time spent, record every new task that you discover, and track your time on those, too. Track with a purpose. Your tracking must validate the basic assumptions that you have made during planning: Have you identified the list of tasks correctly? Have you estimated their size correctly? Have you estimated your productivity correctly? Have you estimated your available hours correctly? When your answer is ‘No,’ then immediately ask: Why not? What caused the discrepancy? Can you figure out the cause of the difference? Can you find a way to correct for this next time?

As you answer some of these questions, you will find that your planning is going to become more accurate over the course of a few planning cycles. The more you have a chance to make a plan, track the plan, and analyze your results, the better you will get at this. This is not magic, not mysticism, it is only simple logic.

If at any time you find something wrong with the plan, you correct it on the spot. Record what you did and why you did it. Your list of corrections also serves to improve your planning.

Practicing the above planning activities may not make you a project planner who can plan the design and implementation of the next air traffic control system that requires coordination across multiple companies and hundreds or thousands of people, but it will make you a competent planner who can plan one’s own work.

In conclusion, to successfully make and meet commitments, you must learn how to plan your own work, understand your performance at doing the kind of work that you need to make commitments about, and continually observe how well are you doing. Your goal is to keep improving both your work and the planning of that work. Becoming proficient at planning and executing your work will enable you to become a much valued member of any team.

Enjoy the journey!

____
References:

  • Watts Humphrey formulated these ideas relative to software development in his book A Discipline for Software Engineering.
  • Peter Drucker talked about concepts related to knowledge workers in many of his writings.

 

Software Development Strategy

, ,

strat-e-gy: a plan of action or policy designed to achieve a major or overall aim.

The New Oxford American Dictionary

The dictionary definition points us in the right direction. The software development strategy is your highest level plan for achieving your software project’s objectives. According to Watts Humphrey, the strategy is “the order in which product functions features or requirements are defined, designed, implemented, and tested.”

What does this mean? This means that the plan of action part of your strategy lays out what you build first, what you build next, and so on. It also lays out how are you going to validate the strategy. The strategy also lays out the policies for risk mitigation and decision making. Sections of the strategy may exists both along the developer – customer continuum and also along the system abstraction levels continuum. For details about these continuums see: Multilevel Planning and Component-Based Development.

The System Architect is responsible for the overall strategy. The strategy has to be sound enough that designers and implementors working on parts of the system receive from it the necessary guidance to aid their technical decisions. A well conceived strategy pushes the decision making down to the lowest possible level, closest to where the problems are encountered, while at the same time provides for the oversight necessary to build a coherent system.

Accompanying the development strategy is the testing strategy. The testing strategy focuses on the various testing activities, including the system validation and verification activities. It is constructed similarly and serves the same purpose as the development strategy, only for testing. The owner of the testing strategy may be the System Test Architect, if there is one, otherwise this is also owned by the System Architect.

Why do you need a strategy? Without a strategy it is difficult, if not impossible, to execute an iterative, incremental development process. The strategy ties the iterations into a coherent whole, and allows the team to move confidently toward the goal. Your first attempt at creating a strategy may feel awkward, but with practice you’ll get better at it. Why don’t you get started today?

What’s the Status?

,

Regardless of the organization you work in, this question probably comes up daily, but at least weekly. To answer the often dreaded status question you need minimum 4 pieces of information.

  1. When did the project start? This is the Start Date.
  2. When is the project expected to end? This is the Expected, Planned, or Estimated End Date.
  3. Where should we be today based on the plan? This is the Expected, Planned, or Estimated % Complete.
  4. Where are we today? This is the Actual % Complete.

If you have the above information then you are able to judge how well you are doing relative to what you said you’d be doing. There is a lot more to project management, but this is a good start.

To get started make a plan for the work you intend to do this week. Write down at least 2 tasks for each day: one task for the morning, one task for the afternoon. This gives you a total of 10 tasks for the week. As you check off the completed tasks, you’ll see your progress bar move. Once you are able to plan your work for a week, plan the next month. Collect your data and adjust.

There is no need for you to wait for your entire organization or team to start doing this. You can get started alone. You’ll be surprised how much better your work will go and how much better you’ll be able to help your team.

Knowledge You Expect To Learn

,

Writing an individual project plan for your project work can be difficult. The secret of creating a workable task plan is to consider not only the work you will complete, but also the knowledge you expect to learn as you perform each task.

As you complete tasks from your plan, two things happen:

  1. you create deliverables, and
  2. you learn.

On a short project you may not be able to learn much. If your project is short, only a week long, then to improve the odds of success, you have to make a plan considering only the knowledge you have at the beginning of the project. One week is generally not sufficient to learn something of consequence that will help you get your project done on time. When you make your plan, focus on the deliverables created by each task. When all tasks are done, the output created must add up to a completed project.

If you notice that you have lots of short projects, then you need to take a more systematic view, and find ways to include learning into your work. Teams that fight fires, each fire being a short project, tend to believe that they don’t have time to learn. They feel that there is never time for learning. However, firefighting is really one long project with lots of short iterations. More on this another time.

On a longer project you must learn. If your project is longer, 2 to 4 months or more, then you must factor learning in the work you are planning to do. More so, you may even want to include deliverables that allow you to verify that learning has occurred. Such deliverables are prototypes, proof of concepts, sample code that you create to demonstrate to yourself (sometimes to others) that you indeed understand the work, the requirements, the API, or some other things related to the project.

Outside of explicit learning-oriented deliverables you also must factor learning into the regular project tasks. Let’s look at an example. You make a plan to create component A and component B. B will be using A through A’s public interface. However, at the time of planning you don’t know exactly how that interface will behave. So you plan for learning.

The knowledge you expect to learn is that you will know exactly how A will behave before you start work on B. This knowledge is pre-requisite for doing the correct work on B. Part of the tasks for creating component A include the writing of A’s unit tests. When you perform this task you will learn how to call A through its public interface. By the time you start work on B, you will have acquired the necessary knowledge to perform the work on B. You didn’t have this knowledge when you made the plan, but you planned for the learning to occur by the time you needed it.

After some practice, factoring into your plans the knowledge you expect to learn will enable you to make more detailed plans for longer horizons with higher accuracy. The challenge is that you need to change the way you think about project work. Plan for learning. Make learning an explicit and expected outcome of each task. You’ll surprise yourself, and your team. Your plans will become ever more accurate.