Monday, February 20, 2017

The open leader

OpenSource.com recently posted a great about "open leaders" and "Why we need open leaders more than ever." In brief, the article discusses how leadership changed in the Twentieth Century with globalism and teams that were geographically displaced. And this new mode of working led to a new kind of leader: the "open leader."

The article makes clear that leadership can happen at all levels of the organization. And I agree! To be most effective, you need to develop your emerging leaders so people can "lead from the balcony" or wherever they are, to provide vision and drive strategic direction. From the article:
As organizations continue becoming more open, even individuals without "leadership" titles feel empowered to drive change. These organizations remove the chains of hierarchy and untether workers to do their jobs in the ways they best see fit. History has exposed 20th century leaders' tendencies to strangle agility through unilateral decision-making and unidirectional information flows. But the new century's leader best defines an organization by the number of individuals it empowers to get something done. There's power in numbers—and, frankly, one leader cannot be in all places at all times, making all the decisions.
The article provides a list of five attributes for the new "open leader":

1. Control
"Where the leaders of old are focused on command-and-control positional power, an open leader cedes organizational control to others via new forms of organizational governance, new technologies, and other means of reducing friction, thereby enabling collective action in a more efficient manner."
2. Communication
"The open leader seeks to engage an organization by sharing information and context (as well as authority) with members of a team."
3. Trust
"Open leaders embrace uncertainty and trust their followers to do the right thing at the right time."
4. Autonomy
"Where the powerful command-and-control 20th century leader is focused on some position of power, an open leader is more interested in the actual role an individual plays within the organization."
5. Empowerment
"Open leaders are focused on granting authority to members of an organization."
How do you compare to the new "open leader"?

Monday, February 13, 2017

How to write an email

Some people claim there's an art to writing an effective email. In my professional career, I follow these general rules for writing emails:
  1. Write email
  2. Delete most of it
  3. Click Send
I find brevity is often best. If I write too much, I may lose my audience. But there's a tipping point: you need to provide a certain amount of context. If you don't "set the stage" or don't provide enough background, your recipient may not understand your message. How little is "too little" in an email?

Let me draw on a few real-life examples. Outside of my regular job, I sometimes teach an online computer science class ("CSCI 4609") at a university. As an online class, we have a flexible class size, although we try to set the "reserve" limit at ten seats. After the first ten students sign up, you need a permission number. But I'll usually give a permission number to whoever asks for one. Usually.

The exception is for students who don't meet the pre-requisite. We require that students take another computer science course ("CSCI 2101") before taking mine. This provides a grounding for the material in "CSCI 4609." Such pre-requisites are not unusual at the university level. If you don't have the pre-requisite, you need to get a permission number from the instructor (me) so you can register for the class.

Let me use a few examples from this class to show how providing a bit of context can make your request more clear:
Too little information
You can imagine my confusion when I received an email like this one from a student who wanted to take my class: (not the actual email, but representative)
Hi. Please give me a permission number so I can register for your class.
Why did this student need a permission number? There were already ten students in the class, so the system might have prompted the student that the class was "at reserve" at the student needed permission to add the class. Or the student might not meet the pre-requisites. I need to know more before I can give a permission number.

In the first example, it's no problem to add the student; I don't mind more students in the class. But if the student didn't meet the pre-requisites, then I need to check that the student won't be in over their head. I want them to succeed in the class, but if they take the class before they understand certain basic concepts, they will find the class very challenging.

I responded to this student to learn more about their situation. Each email was equally brief, requiring us to exchange several more emails before I determined if the student should be added to the class.
Too much information
While it's challenging to respond to too-brief messages, it can be equally difficult to make sense of the small novels that some people send me. Here's another example from a student who wanted to take my class: (not the actual email, but representative)
Hello Professor Hall. I was looking through the catalog to find another class I wanted to take this semester and I saw your class, CSCI 4609. This is a really interesting topic and I'd like to take it. I talked to a few of my friends about it and they think this is something that will really help me after graduation, so now I really want to take your class. I was in the student center last night going through my course registration for Spring semester and I tried to add your class. The registration system is a little difficult to use, so I'm not sure what the message is trying to tell me. When I add your class I get a little red box that pops up and tells me I needed to contact you and get a permission number. But I'm a senior and this will be my last semester before I graduate. I have taken all my other CSCI classes already, and this semester I only have my capstone plus some classes for my minor. I have taken the interface class, last year with Dr. Smith, so I meet the requirements. When you have a moment, I need to get a permission number so I can finish registration in the class. I know we're out of queued registration but your prompt attention would help me to get the class for next semester. I would really appreciate it. Thanks so much!
Okay, wow. That's a lot of information. And the actual email I received was much longer than the sample I wrote for you.

This email is unclear and unintentionally buries the request in an avalanche of extraneous information. I don't need to know where you were when you tried to register for the class. I don't need most of the information here.

Reading long emails like this one seem like more work than reading other emails, because I need to parse the email to figure out what's really going on. Please keep them short for the sake of the person who will read it. Breaking up the email into paragraphs will also make the information more clear.
Just the right information
Let me edit the above email into a message that has just the right amount of information:
Hello Professor Hall,

I would like to take your class, CSCI 4609. I am a senior and have the pre-requisites, but the system says I need a permission number to take the class.

Can you send me a permission number?
That's much easier to read! Notice that the email provides a brief context to "set the stage" before making a simple request? The use of short paragraphs helps the reader to parse the email for the important points: The student has met the requirements, but needs a permission number from me. That's a clear request, and one that doesn't require any follow-up from me.

Monday, February 6, 2017

Above/Below The Line

Across my career, I have helped in several IT consolidations. We are also doing that now in my current position.

IT consolidations can be tricky to communicate. I find the biggest hurdle is explaining how an IT consolidation can help both parties. In most IT consolidation situations, you start with two groups that are managing up and down the "stack" of technology. A key goal is to leverage size and scale so each group takes on the role that is best suited to them, so you simplify the work and let people focus on their value to the organization.

For example, you might have a development team that creates web-based applications for the overall organization. To run their web-based applications, they need a web server, so they install and manage a traditional "LAMP" stack: their own Linux server with Apache, MySQL, and PHP. Except that in most instances, "manage" is an overstatement. The group needs to focus on maintaining the web-based applications they write, and the system administration of the Linux box, MySQL server and Apache instances tend to fall behind. Meanwhile, in another part of the organization, you have an IT infrastructure group that's dedicated to running and maintaining Linux servers, and MySQL databases, and Apache instances.

In examples such as these, IT consolidation makes a lot of sense. If you could peel off the "infrastructure" work from the development team, and move those to the IT infrastructure group, you gain efficiency. The development team can focus on writing new applications, and the infrastructure team can take on the system administration.

Unfortunately, not everyone sees IT consolidation in such plain terms. When you talk about moving part of someone's job into another group, emotions get involved and consolidation becomes more of a challenge than it is meant to be.

To help get around these issues, and communicate more clearly about the benefits of IT consolidation, I've developed a model that helps both sides understand how IT consolidation will work out to everyone's benefit. I call it "Above/Below The Line."

Like most of my examples, I prefer to communicate it visually. Applications come in different forms, so let's envision different examples of an application stack:

Local development
You might have the above example, where an in-house development team writes an application. This usually runs in some kind of framework, such as a web server or other container. Underneath that, you need an operating system, which runs on a physical or virtual server, with storage and network.
Business application
Many applications are instead delivered by a vendor that you just need to run somewhere. A classic example would be a client-server application, but you might have a vendor-delivered application running in a framework, similar to local development. Again, you also need an operating system, which runs on a server, with network and storage behind it.
Databases
Whether the application is locally-developed or vendor-delivered, many will require a database system to store structured data. In terms of the "stack," the data schema is served by a database engine, which runs on an operating system on a server. Network and storage support the overall system.
You should see some similarities here. Each system shares several components or "layers" in an overall "stack." You can draw these components in a simple diagram, such as this:
Local developmentBusiness rulesData schema
Container (web, …)Delivered applicationDatabase software
Operating systemOperating systemOperating system
ServerServerServer
StorageStorageStorage
Network
As I mentioned, before IT consolidation, the development team might manage the entire "stack" in order to support their application. But post-consolidation, you need to separate what is "application" from what is "infrastructure" by defining roles. Having described the "stack," the next step is to define the separation of roles. Let me use color here: green to represent the application team and blue for the infrastructure team:
Local developmentBusiness rulesData schema
Container (web, …)Delivered applicationDatabase software
Operating systemOperating systemOperating system
ServerServerServer
StorageStorageStorage
Network
I've added an obvious line to indicate where most organizations choose to separate roles. After IT consolidation, the application team operates "above" the line, managing the local application development, configuring containers, managing business rules for vendor-delivered applications, managing data and database software. In this model, the infrastructure team operates "below" the line, supporting the operating system, servers, storage, and network.

This is a great model, but it's also a simple model. In any realistic environment, I find you need to make certain exceptions. You'll always need some cooperation between the two teams. The purple line becomes more difficult to draw, because it's position will differ based on your environment. An obvious example is installing software; in most organizations, the infrastructure team may need to be involved to install applications. Although usually the application team can take things after that:
Local developmentBusiness rulesData schema
Container (web, …)Delivered applicationDatabase software
Operating systemOperating systemOperating system
ServerServerServer
StorageStorageStorage
Network
And the opposite is sometimes true: the application team may need to do some things at the operating system level. For example, in a Linux system, the application team often is allowed to configure the web server software, and stop and start it using operating system rules (such as sudo). The line becomes less clear, but it is still visible:
Local developmentBusiness rulesData schema
Container (web, …)Delivered applicationDatabase software
Operating systemOperating systemOperating system
ServerServerServer
StorageStorageStorage
Network
I created the "Above/Below The Line" model before Cloud was a thing. But Cloud applications are easy to fit into the diagram. Cloud applications are hosted externally, similar to vendor-hosted applications. So Cloud applications rely on the organization's network, but otherwise live completely "above" the line. An integration team (which might be the same as the application team) manages business rules in the Cloud application.
Local developmentBusiness rulesData schemaBusiness rules
Container (web, …)Delivered applicationDatabase softwareCloud application
Operating systemOperating systemOperating system
ServerServerServer
StorageStorageStorage
Network
When I've shaped an IT consolidation discussion using this framework, I find we experience fewer miscommunications and less stress. The "Above/Below The Line" model helps both sides understand the roles involved after IT consolidation. The key takeaway is the infrastructure team does the "heavy lifting" of managing operating systems, servers, storage and networks so the application team can focus on what they do best: building and supporting applications that drive the business.

Monday, January 30, 2017

Audiobooks

I've always loved audiobooks for longer than I knew the term "audiobook."

When we were growing up, my brother and I always read at a higher grade level. And to encourage us to read more, our parents would often read books to us. Our mom sometimes recorded herself when she read, so we could listen to the tapes again during down time.

During summer vacations, we would often take road trips to visit family. We're talking a really long car ride here, not a simple one-hour journey, but a cross-country trek. We lived in Minnesota, but our extended family all lived in Virginia and North Carolina. That's about eighteen hours non-stop, but well over twenty-four hours if you include stops. To keep me and my brother from getting fidgety, our parents played audio cassettes of radio programs. I developed a love of radio, from the original 1938 broadcast of War of the Worlds to comedy groups like Duck's Breath Mystery Theatre to other productions from National Public Radio (Star Wars, The Hobbit, Connecticut Yankee in King Arthur's Court, etc).

As an adult, audiobooks became a great way to pass the time during my hour-long bus commute to and from work. I started with the ever-popular Walkman to listen to audio cassettes, but later upgraded to an iPod. Listening to a great story made the ride go by more quickly. And most tapes were about twenty-five minutes per side, fifty for both sides, so when I finished side B, I knew it was almost time for my stop.

Audiobooks let me expand my genre. I enjoyed some titles that I probably wouldn't have read in print. The Silmarillion was interesting as an audiobook, but not usually what I would read. And I doubt I would have read the Harry Potter series in print, but they worked great as an audiobook series, read by the talented Jim Dale.

In 2010, I took a new job. Unfortunately, it meant a three hour commute to drive back to the Twin Cities for occasional meetings. And around the time I entered grad school, that became a weekly drive. But audiobooks helped pass the time. I lived by the books on my iPod. The long drive almost became something I looked forward to, because it meant listening to another audiobook.

Somewhere in there, I discovered Big Finish! They have the license to do new audio productions based on classic Doctor Who. But it's all new stuff. And as a big Doctor Who nerd, this was perfect! Big Finish appealed both to my love of audiobooks and to my classic fandom. My first story was Spare Parts, a Fifth Doctor and Nyssa story featuring the origins of the Cybermen, and immediately I was hooked! Over the years, I've picked up a majority of the Big Finish back-catalog. I try to stay current on the new stuff too.

They have a ton of spin-offs too, like I,Davros and UNIT and Dalek Empire and Cybermen and Unbound and Gallifrey and Counter-Measures and Jago & Litefoot. And other series, especially Blake's 7 and Survivors.

I still listen to a lot of audiobooks, but most of my collection is filled with Big Finish. Whenever I recommend audiobooks to folks, I always include a few Big Finish titles in the list.

So if you're looking for an audiobook recommendation, hit me up. I'm glad to recommend a few.

Monday, January 23, 2017

The XY problem

There's an interesting phenomenon in asking questions: we often ask help to solve the wrong thing. In certain circles, this is called the XY problem, summarized here:
  1. You want to do X
  2. You don't know how to do X, but you think you can get there by doing Y
  3. You don't know how to do Y
  4. You ask for help to do Y
The XY problem is asking about your attempted solution rather than your actual problem. But you won't get much useful help in asking to do Y, because you aren't really trying to solve Y. You're trying to solve X, yet you've invested so much time and energy on your possible solution involving Y that you forget to mention that X is the real problem.

As a result, folks may offer solutions to Y that technically work for Y, but don't help you with X. And that's not very helpful.

I see this happen across the board, in my work with open source software and in my professional career. Even I'm not immune to it; I may decide on a particular solution, and ask for help with that solution. But by not providing the full context of the problem I'm really trying to solve, others aren't able to help me that much.

Use your words. When you have a problem or make a request, tell people what problem you are trying to solve, and what solution you are currently chasing.

Monday, January 16, 2017

Don't check email in the morning

Many of us seem connected to our personal devices, like our phone. We check email, do Twitter and Facebook, read websites and blogs, watch videos… we do everything. Our personal technology has become part of our lives, like a habit.

And like a habit, I'll bet many have this bad habit: you check email first-thing in in the morning.

But checking email right away when you get up is ruining your work-life balance. You aren't staying separated from "work" when you are at home. And checking email in the morning can ruin your day, according to Michelle Gielan, former national CBS News anchor turned psychology researcher and best-selling author.

According to Gielan, even one bad email can set a negative tone for your day. And that rings true for me, certainly. I try not to read email over breakfast, but when I do, one bad item can put me in a poor mood for much of my work day.

If you must check email in the mornings, Gielan recommends instead to put yourself in the right frame of mind before doing work emails. Take a few minutes to send a positive email to someone you know well, like a friend or a family member. From the article:

After you send your upbeat email, move on to your regular routine of checking your work email or the news.

That two-minute message primes your brain to see everything in a more positive light.

“It will change how you process your day and how you process your email at 2 o’clock in the afternoon,” she says.

My best recommendation is to preserve your work-life separation, and avoid work email at home when you can. But for those times when you do need to check work email, Gielan's recommendations may help.
image: William Hook (CC by-sa)

Monday, January 9, 2017

On resource planning

As a young manager many years ago, I didn't really know how to manage people. I just didn't have any training for that. So when I needed to assign staff resources to projects, I did it ad hoc. I tried my best, but it came down to asking who was interested in a project, and making a selection based on who had the best availability.

The problem with ad hoc planning is that you aren't really planning. There's very little thinking ahead.

Later in my career, I worked with someone who was a professional planner. As a former project management consultant, this person really understood how to do project and resource planning. I learned from him that there are many ways to do thoughtful resource planning, and from him I derived a method of resource planning that has served me well these many years later. I'd like to share it with you.

If you do project planning or work as a project manager, this method may seem very familiar to you. But if you haven't done resource planning before, I hope this will be helpful to you.

You don't need a fancy tool to do resource planning, although there are professional tools to do much of the work for you. But a spreadsheet works well enough, especially if you are just getting started in resource planning. So let's do this example with a spreadsheet.

Start by thinking about a time frame. How far out can you do planning in your organization? If you're like me, one month is too short, and six months is too long. Things change more quickly than a six month time frame can accommodate, but not fast enough for a one month window. I use a three month time frame. This gives me a quarterly work plan.

There are 52 weeks in a year, 26 weeks in half a year, and 13 weeks in a quarter. So create your work plan by creating 13 columns, one column for each week. I also recommend you include the date of each week as a separate row—although for this example, I'll leave that out. Leave a few columns to the left; we will fill these in later:
12345678910111213

Now, think about the work that you will need to get done over the next quarter. What work does your organization need to get done? What are the priorities from your leadership? What are the major projects? Put these on separate rows in the first column.

Don't forget that support activities also count here. For example, you may have systems administrators who need to keep servers running. Same for network administrators supporting your network. You need to include these too.

Once you have the major projects, determine how the projects break down by tasks. A project consists of many steps. What are the components to complete the project? List the steps in the second column.

Then, identify the resources you have available. What projects are they best suited for? What are their skills? Where can you best direct their energies? Who would be the best contributor for each project? Don't forget that only very small projects require just one person; most projects will require more than one contributor. List the people for each task in the third column.

In this example, let's assume two "infrastructure" team members (John and Jane) and two developers (Jill and Jack). As we start the quarter, the developers are starting a new project (Project1) while they prepare to deploy a previous one (Project2).
12345678910111213
Support
networkJohn
serverJane
databaseJane
Project1
analysisJill
designJack
devJill
devJack
Project2
testJill
testJack
rolloutJill
rolloutJack

As you identify new projects and tasks, keep the spreadsheet organized. In this example, see how separate projects start on their own row. Tasks are matched with a resource. I've kept my example somewhat simple by not providing much detail. If you were writing your own resource plan, you would likely need to fill in more information about the project and tasks.

Look ahead by weeks and consider how long each task will take. If this is your first time building a resource plan, you might "block out" some time by filling in each week with a color that you can go back to later. Let's do that for the example. I'll block out some time. Note that the support tasks should be blocked out for the whole quarter, but other tasks in other projects might take different amounts of time.
12345678910111213
Support
networkJohn
serverJane
databaseJane
Project1
analysisJill
designJack
devJill
devJack
Project2
testJill
testJack
rolloutJill
rolloutJack

From here, you need to assign time or "effort" each week to every person working on every task in each project. You can do this a few different ways. Professional project managers sometimes prefer to use a four-day work week, where you always assume one day is "lost" to "overhead" (usually meetings). I prefer to use a five-day work week. I find my staff understand the five-day work week better if they can build in their own "overhead" and see where their time is going. This also allows some flexibility. For example, developers may need to attend more meetings for project planning, etc. Let's assign time to each project with the assumption that John and Jane attend fewer meetings than Jill and Jack.
12345678910111213
Support
networkJohn5.05.05.05.05.05.05.05.05.05.05.05.05.0
serverJane5.05.05.05.05.05.05.05.05.05.05.05.05.0
databaseJane5.05.05.05.05.05.05.05.05.05.05.05.05.0
Project1
analysisJill5.05.05.05.0
designJack5.05.05.05.0
devJill5.05.05.05.05.0
devJack5.05.05.05.05.0
Project2
testJill5.05.05.05.05.05.0
testJack5.05.05.05.05.05.0
rolloutJill5.05.0
rolloutJack5.05.0
meetings

John1.01.01.01.01.01.01.01.01.01.01.01.01.0

Jane1.01.01.01.01.01.01.01.01.01.01.01.01.0

Jill1.51.51.51.51.51.51.51.51.51.51.51.51.5

Jack1.51.51.51.51.51.51.51.51.51.51.51.51.5

Look at every column, and make sure the total time for any one person adds up only to 5.0 every week. There are only five days in each week, you can't expect your team members to work more than five days. In the above, Jane is over-committed on "server" and "database." Similarly, Jill and Jack are over-committed across "Project1" and "Project2."

When considering the balance of time, I prefer to use a few simple rules: The smallest increment of time allowed is 0.5 days per week. That's four hours of work time, and I find you cannot really plan for time less than four hours per week.

As you balance the time committed to each project, consider the work load. For example, Jane's dual responsibilities as server administrator and database administrator may not require equal time. Perhaps she spends most of her time maintaining the server.

And don't forget about vacations and holidays. Everyone needs time off, and you need to plan for that. Build your holidays into your work plan from the beginning. Ask staff to estimate their upcoming vacation time. While folks might take an unplanned day off here and there (or be out sick) you can still plan in advance for extended absences such as a long vacation.
12345678910111213
Support
networkJohn4.04.04.04.04.04.04.0x4.04.04.04.04.0
serverJane3.03.03.03.03.03.03.03.03.03.0x3.03.0
databaseJane1.01.01.01.01.01.01.01.01.01.0x1.01.0
Project1
analysisJill1.51.51.51.5
designJack3.03.03.03.0
devJill2.52.53.53.53.5
devJack3.53.53.53.53.5
Project2
testJill2.02.02.02.03.53.5
testJack3.53.53.03.50.50.5
rolloutJill3.53.5
rolloutJack0.50.5
meetings

John1.01.01.01.01.01.01.0x1.01.01.01.01.0

Jane1.01.01.01.01.01.01.01.01.01.0x1.01.0

Jill1.51.51.51.51.51.51.51.50.50.51.51.51.5

Jack1.51.51.01.51.51.51.51.51.51.51.51.51.5
vac/hol

John1.05.0

Jane1.05.0

Jill1.0
2.02.0

Jack1.01.0

As you can see in the work plan, Jane plans to divide her time between "server" and "database" tasks. For the first eight weeks of the quarter, Jill and Jack each will spend some time on analysis and design for "Project1," and the remainder of this time doing testing for "Project2." See under "Project2" how Jack ramps down on testing at the same time Jill ramps up, because of his balance of responsibilities.

Also, Jack gets to turn a holiday on week 2 into a four-day weekend in week 3, while Jill takes an extended vacation during weeks 9 and 10. John takes the whole of week 8 as vacation, and Jane takes all of week 11. When each person is out, notice that their time on other projects also needs to be redistributed.

That balances the time assigned to projects. No one gets overloaded. And everyone gets to take their vacations. The staff can be productive, while the manager is able to plan for their work.

With that, you have the start of a quarterly resource work plan!

You can add other features to this work plan. Here are a few ways to extend this:
Total time
As you build your work plan, it quickly becomes cumbersome to add up everyone's time each week, and ensure every person is allocated "5.0" days per week. Let the spreadsheet do the work for you. Look up the =SUMIF() function to make this easier. The =SUMIF() function is a standard spreadsheet function to add numbers from a column only if a key matches one in a list. In calculating total time, the key is the name of each staff person. I also use automatic formatting in my spreadsheet to highlight the total in a different color if the value is less than, equal to, or greater than "5.0." This helps me to quickly identify where staff are over-committed as we build the work plan.
Reporting
As you progress through the quarter, how do you track when people actually work on projects? When I "borrowed" the work plan spreadsheet from my colleague, he used separate tabs in the spreadsheet for staff to report time. Entering time into the spreadsheet required staff to track hours worked against each planned work item, and provide an estimate to completion. This sounds great, but ended up being very confusing, especially for folks in a primarily "support" role. Later, I asked my teams to report their status using a simple metric: don't change the numbers in the work plan, but highlight each cell to indicate when you worked on something. Highlight in green if your project is progressing well, yellow if you encounter issues that might put your project behind schedule, and red if the project is at risk. Then I would review the spreadsheet every week as part of my staff meetings to see how things are going. If I saw any yellow or red for the previous week, we would go over that and talk about issues and how to move things forward.
Unplanned work
You can't really plan for unplanned work, but sometimes things just happen that require staff to drop everything and make some work item their number one priority. In higher education, the dean might ask us to work on a special project. This was unplanned work, and it certainly had an impact on our time. To account for unplanned work, I would add a few rows to the bottom of the spreadsheet, one row per staff member, and reserve this row for unplanned work. If you worked on an emergency project that wasn't on our list, you would record the time worked in your "unplanned work" row, and use a spreadsheet cell comment to indicate the unplanned work item. If this unplanned work impacted another planned work item, the staff member would highlight that other project's status with yellow or red to flag it for the manager. This ended up being a good balance of reporting time without over-burdening staff to fill out a weekly status report.
Roll-up reporting
Sometimes it's helpful for a manager to provide a "roll-up" report of how their team spends their time. This kind of "roll-up" requires adding a new column to the work plan to categorize the type of work. I borrowed from other professional project planners and developed a "code" to represent the type of work:
AN Analyze: Time dedicated to understanding a project or doing background work about the project.
DE Design: Designing a solution.
BU Build: The creation of a system.
TE Test: Time dedicated to testing a new system.
DP Deploy: Rolling out a new solution.
P Project: Use this if your project doesn’t use defined phases like Analysis, Design, Build, etc.
PM Project management: Usually reserved for managers who need to report time.
CF Change-fix, or production support.
NP Non-project time, such as vacations and holidays.
UW Unplanned work: Time spent on emergencies or last-minute important work requests that were not planned. By definition, do not plan for UW.
Once you have a code entered for each task on the work plan, you can create a simple roll-up report to show how time has been allocated. Again, let the spreadsheet do this work for you. The =SUMIF() function can use the code as the key to generate the total time for each code. This lets you build a matrix to calculate the total time spent each week for each type of work.