Put down the code.

As a development manager, I have requested work breakdown structures (WBS) many times from the dev leads. Everyone has their own approach and why it takes sometimes days to get this simple list is often frustrating. Here is a simple way to get that elusive WBS done in 30 minutes and have 125 items in your list – well, 126.

The WBS is made up of parent-child entities representing the overall outcome of the project. At the bottom of the hierarchical list should be the task item that a developer would perform in support of the branch in the list or WBS. Because I work with different dev leads on every project, I always ask the “what time value would you like to see at the lowest task in order to assign it to a developer and ensure it gets done within the timeframe”. I am particular to a task being 8 hours. Some like 8 to 24 hours. Stay away from tasks defaulting to 1 week. The task becomes way to vague and hard to manage completeness, especially on short budgets.

As a developer, your focus is identifying the tasks you to accomplish in order to deliver the product. As a project manager, you will take the developer's WBS and add all the “other stuff” like quality testing, meetings, documentation, transition to maintenance, etc…

Start your exercise with the name of the product you are delivering as a result of the project. You should be able to represent what you are building and deploying with one to three words. Example;

XYZ
Public Website
Middleware BizTalk Application

The reason you start with that single identifier is to always see the list as the product. It helps during each of the next three passes.

Now, choose 5 tasks which in their entirety represent the product you will be delivering and add them to list under the product name you created earlier;

Public Website
    Security
    Sites
    Infrastructure
    Publishing
    Creative

Continue this concept of seeing the list as the complete picture and decompose it one more level. You should have 25 items.

Public Website
    Security
        Authentication
        Login Control
        Administration
        DRM
        Workflow
    Sites
        Masterpages
        Page Layouts
        Web Parts (RIA, Multimedia)
        Content Types
        Structures
    Infrastructure
        ...
    Publishing
        ...
    Creative
        ...

And one more time for a total of 125 items. The top item makes the list 126.

Public Website
    Security
        Authentication
            Install (AD/ADAM/LDAP/SQL)
            Configuration
            Management
            Web App Configuration
            Implement Provider
        Login Control
            Login Form
            Login/Logoff
            pw change
            pw recover/forgot
            email verification
        Administration
            ...
        DRM
            ...
        Workflow
            ...
    Sites
        Masterpages
        Page Layouts
        Web Parts (RIA, Multimedia)
        Content Types
        Structures
    Infrastructure
        ...
    Publishing
        ...
    Creative
        ...

The next step is to make sure the task at the bottom of every branch represents the “time value” you planned for the project. You can add more to the WBS and of course if you can’t find 5 items, 4 is fine. If a task can be done in a fraction of the time value you determined for the project, try to roll it up into a larger task. In the task actions (later when the iteration is being planned), decompose the details back to the simple tasks.

Now, go estimate!

The scenario;

A small team of 3 developers mostly in maintenance mode with traditional ASP.net, classic ASP, .Net integration services and utilities with the company’s third party packages, and a bunch of java-based Coldfusion web applications all under Visual Source Safe (VSS). They are about to embark on a huge SharePoint 2010 new construction project and wanted to use subversion instead VSS. TFS was a foreign word and smelled of “high cost” and of an “over complicated process”. Since they had no preconditions about the old TFS versions (‘05 & ‘08), it was fun explaining how simple it was to install a TFS server and get the ball rolling, with or without all the heavy stuff one sometimes associates with such a huge and powerful application management lifecycle product.

So, how does a small team begin using TFS?

1. Start by using source control and migrate current VSS source trees into TFS. You can take the latest version or migrate the entire version history. It’s up to you on whether you want a clean start or need quick access to all the version notes and history of the bits.

2. Since most shops are mainly in maintenance mode with existing applications, begin using bug workitems for everything. When you receive an issue/bug from your current tracking system, manually enter the workitem in TFS right through Visual Studio. You can automate the integration to the current tracking system later or replace it entirely. Believe me, this thing is powerful and can handle even the largest of help desks.

3. With new construction, begin work with requirements and task workitems and follow the traditional sprint-based development lifecycle. Obviously, some minor training will be needed, but don’t fear, this is very intuitive and MSDN has a ton of lesson based labs and videos.

4. For the java developers, use the new Team Explorer Everywhere 2010 plugin (recently known as Teamprise). There is a seamless interface in Eclipse, but also a good command-line utility for other environments such as Dreamweaver.

5. Wait to fully integrate the whole workitem/project management/testing process until your team is familiar with the integrated workitems for bugs and code. After a while, you will see the team wanting more transparency into the work they are all doing and naturally, everyone will want workitems to help them organize the chaos!

6. Management will be limited in the value of the reports until you have a fully blown implementation of project planning, construction, build, deployment and testing. However, there are some basic “bug rate” reports and current backlog listings that can provide good information.

Some notable explanations of TFS;

Work Item Tracking and Project Management - A workitem represents the unit of work within the system which enables tracking of all activities produced by a user, whether it is a developer, business user, project manager or tester. The properties of a workitem such as linked changesets (checked-in code), who updated the data and when, the states and reasons for change, are all transitioned to a data warehouse within TFS for reporting purposes. A workitem can be defines as a "bug", "requirement", test case", or a "change request". They drive the work effort by the individual assigned to it and also provide a key role in defining what needs to be done. Workitems are the things the team needs to do to accomplish a goal.

Test Case Management - Starting with a workitem known as a "test case", a tester (or developer) can now author and manage test cases within a formal test plan subsystem. Although TFS supports the test case workitem type, there is a new product known as the VS Test Professional 2010 which allows a tester to facilitate manual tests including fast forwarding steps in the process to arrive at the assertion point quickly. This repeatable process provides quick regression tests and can be conducted by the business user to ensure completeness during UAT. In addition, developers no longer can provide a response to a bug with the line "cannot reproduce". With every test run, attachments including the recorded session, captured environment configurations and settings, screen shots, intellitrace (debugging history), and in some cases if the lab manager is being used, a snapshot of the tested environment is available.

Version Control - A modern system allowing shared check-in/check-out, excellent merge conflict resolution, Shelvesets (personal check-ins), branching/merging visualization, public workspaces, gated check-ins, security hierarchy capabilities, and changeset/workitem tracking. Knowing what was done with the code by any developer has become much easier to picture and resolve issues.

Team Build - Automate the compilation process whether you need it to be whenever a developer checks-in code, periodically such as nightly builds for testers in the morning, or manual builds to be deployed into production. Each build can run through pre-determined tests, perform code analysis to see if the developer conforms to the team standards, and reject the build if either fails.

Project Portal & Reporting - Provide management with a dashboard with insight into the project(s). "Where are we" in each step of the way including past iterations and the current burndown rate. Enabling this feature is easy as it seamlessly interfaces with existing SharePoint implementations.

Getting my geek on…

I have decided to call the products VS.10 (Visual Studio 2010), TP.10 (Test Professional 2010),  and TFS.10 (Team Foundation Server 2010)

Thanks Neno Loje.

Since my first UUCP operation in UNIX to deliver and receive an email, I have always been challenged to find the ultimate email organizer. About a year ago, I switched to a very simple process of managing email and have found the ultimate in organization. On the craziest of days with 250+ emails, I keep my inbox empty. Here is how I do it;

First, start with the following folders in your mailbox;

Inbox
   Archive
   FollowUp
   Hold

Of course, all inbound emails will start in the Inbox. As you work throughout the day, follow these steps to keep your inbox empty;

1. Read the email.
2. Are you responsible for any action? If you are and can do it immediately, then do it. If you need to do it later, move the email to the “FollowUp” folder. When you are done with the task, move it to the Archive folder (Not Outlook archive)
3. If you are not responsible for any action, move it to the archive folder. Use Outlook’s search to find them when you need them.
4. If you will need to reference the email later in the week or for a short term (week or two), then move the email to the “Hold” folder
5. As your day progresses, frequently review the FollowUp folder and accomplish the task

*Notes:

• If I am waiting for someone to do something for me, I keep it in the FollowUp folder. As I review the folder, I am constantly reminded that there is something I am waiting on – and can send a simple reminder by forwarding the original email.
• I sometimes send myself a “todo” email and park it in the FollowUp folder

I like to know how many emails are in the folders so I set the “Show total number of items” property on the folder to show the amount of emails.

I wrote this two years ago and thought it was worth posting…

Some may think this is a daunting task and some may even say “what a waste of time” and want to open MS Project and start typing out tasks because someone asked for an estimate and a task list. Hell, maybe you even use Excel and pump out a spreadsheet with some real scientific formula for guessing how long it will take to code a bunch of classes. However, this short exercise will provide the basis for the entire project, whether small or large and be a great friend when communicating to anyone on your team or even your client. I call this the Project Brief. If you find yourself going beyond a single page, then you must decompose the sections and summarize your findings so there is a complete and clear picture of the project you are working on in a relatively short statement. Here is a great quote from the PMBOK (Project Management Body of Knowledge) relative to what a project is;

A project is a temporary endeavor undertaken to create a unique product, service or result.

With this in mind, the project brief should encompass the entirety (objective) of the endeavor in its explanation and what it will take (goals) to create the product, service or result (deliverables).

Normally the process of identifying the project objective is done during the first stage of a project called the Project Kickoff, but you can perform this very important step anytime to help you get a bearing. There are many more parts to helping a project stay on course, but this is usually the foundation where it can be grounded on.

Through a series of 3 exercises, you should be able to come up with the objective, goals and deliverables on your project. Follow these steps, and in no time (about ½ hour), you will have the foundation of your project plan. (See examples below)

Exercise 1 – Objectives
Begin with the end in mind. Think about your project in business terms with a couple things to help you understand the objective;

• Reference the business benefit in terms of cost, speed and / or quality,
• Provide a higher level of what the outcome will look like (future sense)
• It should be non-measurable, that’s what the goals are all about

The output should be a single paragraph with three sentences and take 10 minutes to write.

*Typically, agreement must be reached on the objectives of the project before you would proceed to the next steps of the project.

Exercise 2 – Goals

A project goal is a statement that answers questions about who, what, why, where and when. A good project goal statement;

1. Answers the five “W” questions for the project
2. Is measurable in each of its parts
3. Is published and agreed on by all the owners

This helps the Project Manager receive confirmation on defining the project target.

Using the established project objective done in the first exercise, think about the things it will take to get the job done. Think about tangible activities which are the top level tasks in a typical Work Breakdown Structure (WBS). The overall goal statement plus all the deliverables (next exercise) can be seen as the project team’s contract with the project owners.

Write 3 - 5 goals in about 10 minutes. You should not write the words “Who, what, why, where and when, but merely be able to answer the questions when you read a goal.

Exercise 3 – Deliverables

Every project creates some type of output and these outputs are called deliverables. There are two classes of deliverables;

• Internal – produced for project team members to meet their goals
• External – produced for project owners to meet their expectations

The list you enter here provides a checklist for the team’s delivery and/or is a statement of all the expectations of the project owners. Here are some typical project deliverables;

Product and product documentation

Plans

Reports and general documentation

Deliverables should go with each of the goals. Have 3-5 deliverables for each goal. When you are done, you will have established a great foundation for the clarity of your project. This exercise can take some time, but with practice, you should be able to whip this one out in 10 minutes as well, especially if you are intimate with an ongoing project.

Samples 

Objective

[Client] is implementing a series of MOSS sites to support external public (Internet), internal employee (Intranet) and an external secure (password protected Internet) applications. This project will focus on the public-facing web site and will provide [Client] with architectural recommendations based on the current design being done by their design partner [Partner] and the internal Content Team. In addition, it will provide [Client] with a development plan and confidence they need to deploy a world class public Internet website.

Goals

1.  [Consultant] will provide technical guidance and set project team expectations for the implementation of the MOSS Internet site based on provided features/functions within three weeks.

2.  [Consultant] will understand phase 2 secure password-protected Internet site design and provide recommendations.
 

Deliverables

1.1  Public Internet (unsecure) Architectural Recommendation Plan

1.2  Physical Site construction Work Breakdown Structure and plan (Time, cost and resources needed)

2.1  Two Factor authentication recommendation document
 

Objective

[Client] is currently using an application developed by [Consultant] many years ago called "XXX". This application, although functional, does not meet their new updated business requirements and contains a few defects which [Client] has developed work-around processes. [Client] would like to have a "new and improved" system to support their membership management needs by expanding membership and subscription capabilities, provide accounting integration with internal (GL) and external (VeriSign) systems, and implement hooks to the current CRM solution. This effort will take place through a series of phases, beginning with envisioning.

Goals

1. Through discussions with users, [Consultant] will discover current issues/bugs which need to be resolved which must meet the current functionality requirements within three weeks.

2. [Consultant] will gather requirements from the users about what is "needed" vs. "what they have" for enhancements and provide a high level document supporting their needs.

3. [Consultant] will meet with the team members through a series of meetings and help define the overall project plan to deliver a new and improved solution.

Deliverables

1.1 Prioritized list of Current application issues/bugs that need to be resolved

1.2 Provide a resolution plan on the issues/bugs identified in the current application

1.3 Risk Assessment Document

2.1 Deliver a Requirements Document showing high-level [Client] needs for the new XXX application.

· New feature functionality not in the application today

· Existing functionality that will remain in the new functionality

2.2 Reporting Requirements Document

3.1 A Project Plan showing the deliverables and cost for the next (second) phase of this project.

3.2 A Statement of Work for the next (second) phase of this project.

3.3 An Estimate of any work that would need to follow the second phase.

From a colleague of mine…

“As a project manager, when do you typically like to get initially involved in the project? Is it better for the PM to be rolled on during the project kick-off, the first week, or is it better to roll-on the second week when things settle down?”

My textbook answer is “the Project Manager is responsible for the successful completion and delivery of the expected outcome of the project through the following major tasks;”

1.    Identifying requirements
2.    Establishing clear and achievable objectives
3.    Balancing the competing demands for quality, scope, time, and cost
4.    Adapting the specifications, plans, and approach to the different concerns and expectations of the various stakeholders

However;

My colleague is often a lead technical consultant coming into a project alone to help a client solve a complex problem. As Magenic consultants, we all possess many of the “project managing” skills I talked about above and tend to be responsible for item #1 and #2 as well as the actual architecture/design tasks early in a project.

When the real development begins and there is no PM involved, the project will quickly get harder to execute unless items #3 & #4 are assigned to a Project Manager. In software development, the concept of context switching between coding and other administrative activities is the hardest skill perfect. In my experience, I have rarely been introduced to someone who has mastered this skill. This is the limbo I was in when I was asked to become a PM -- while still developing. “Put down the code” was not only a profound statement, but looking back – a necessary one. Unless you are lucky to have found that one developer who is a superman, asking your developers (internal corporate or consultant) to perform #3 and #4 tasks, will surely take more time, allow opportunity for more scope, and eventually cost more.

Project Managers are crucial to the overall success of a project, and I prefer them to start by taking ownership of delivery on day one.

Whenever I start a new project or come in during a hectic time to help salvage a deliverable – there is always a backlog. Generating the backlog can be a daunting exercise, but worth the effort. Once I have a backlog, I feel in control and the chaos begins to quell.

In your everyday life, you too should keep a backlog. Here is how I do it;

1. Always carry a notebook

2. Start each day marking a new page with today’s date

3. Flip to yesterday’s notes and copy every task with an empty checkbox next to it, to the new empty page (today)

4. As the day progresses and you go to meetings, do your work, or get interrupted to do something…jot it down in today’s page and put an empty checkbox next to it. If you get it done during the day, awesome. Mark it complete.

Keep carrying and writing every task to each new day until it is complete. Maybe one day, you will have an empty backlog and your sprint will be complete!

Asked by many of my colleagues often enough, I decided to take the plunge and begin blogging. After many attempts to start and long discussions about what I should write about, I decided to give my “buddies” a series of lessons and tidbits to help them understand what it takes to manage a software development project in the real world. Stories of success and failure to keep hope alive.

I am formally trained as a developer (BS/CS) and have scattered my code throughout the matrix since 1985 (officially working for the man). As I moved from job-to-job over my career, I have had good managers, bad ones, and ones who were – well, just sitting in the corner office. It wasn't until I began the transition and commitment to the role of project management that I began to take real software development management seriously.

A boss once told me “put down the code. Start managing the people and process.” That was a scary time in my career. I loved solving really cool problems with a blank sheet of paper. It was an adrenaline rush to get an opportunity to start from scratch and write an application solution people would actually use and help them in their work/business. I felt that moving into “management” would remove me from the thrill and ownership I felt as a developer. It was a hard step to take, and one which I believe is hard for any developer.

Well, I am here to help you through this transition. For those of you wanting to read my stories or learn about the tools and techniques I use on a daily basis, you too might just learn something you would have never thought of as an architect/developer.

I am currently a Sr. Consultant at Magenic with the Boston branch office and primarily work with clients in the New England area. I am typically engaged as the lead project manager on our engagements, but also perform Application Lifecycle Management (ALM) assessments for development organizations as well as augment the Technical Evangelists for Microsoft and perform many Team Foundation Server (TFS) demos, installs and “get started” engagements. I have spoken at the New England Code Camp, our most recent CodeMastery event in Boston, and have written several whitepapers.

I am looking forward to helping you “Put down the code.”

John Doucette