Documentation - How To Article

Here's a GREAT link to an article about project documentation: http://www.xprogramming.com/xpmag/Ferlazzo.htm

Documentation should be factored into the project and not an afterthought and should be part of the development/execution process - and not a series of written to die documents. Documentation should add value and reduce risk - why else do it?

Know Thy Data

Data is often thought of as numbers, letters, binary setting - Wikipedia has an in depth interesting description. Data is mapped, reported on, used, converted, imported and transformed.

What most people (IT Professionals - I'm assuming most are people) forget is what the data is and why it is and because of this systems are often incorrectly constructed. The biggest issues that I have seen in system development are due to a lack of understanding of the information (aka data) being manipulated. Programmers often see data in terms of counts, types, relationships, uses - what they don't see is what the data represents and the value of it. A programmer will mangle thousands of records normalizing and de-normalizing as needed to get the best performance with a generic view of the data. What MOST lack is the understanding of what the data is, they see it as letters and numbers, could be a '1' could be a 'z', all the need to know is if it's part of a field being used in a index or a field that will be updated or calculated. What should they care..right?

Well, let's first start with a very basic understanding that isn't understood by many, DATA is often the bulk of the value of any system, not the program code, not the server, not even the developer's time. Without data what value would a customer database have? What value would a inventory system have? NONE! An empty inventory system is a cost, one that is full of data, reflecting a businesses stock is priceless. Keep that in perspective.

Let's move on.

If a programmer (DBA, DBD or whatever you would like to be called) does not understand the data they are manipulating, how could they effectively design, store or program against it? A two char field? What could it be? A state? A prefix? A medical code? Better know it. Let's assume it's a state, let's normalize it add a state table and then associate it with a numeric key for better normalization - right? Yep, you never know when another state will be added or removed, happens all the time, could be 2 or could be 1,000 of them in the database. What if the data could only reflect information for up to 2 states? The only states that the company does business in and perhaps the company might grow into another state within 3-5 years. Still makes sense to separate the state out into it's own table? What about all that SQL code you built to handle the generic possibilities? Better optimization if you knew there could be only 2 or at most 3 in the next 3-5 years? MOST LIKELY. Many programmers will retort that they should not be focused on what the data means because generic solutions are the best - that's just BS - generic solutions are the simplest. Do what you're trained to do and design systems based on the elements that bring the most value - in most cases the DATA.

Communication

It's amazing how much communication goes on without people even realizing it. Communication is an intense subject that everyone does naturally, but few understand even the basics...including myself.

Every move you make, every sound you intone, things you wear, how you write an your prior history contributes to the message. Communication is impacted on time and culture. What may be a positive message today might be looked at differently tomorrow based on what has transpired between.

Rudolf Arheim book on Art and Visual Perception is a great starting point in how information is transferred and what impacts the receiver. What can be said for art can be easily applied to verbal communication and in the end they all tie in together. Another great read is ANYTHING from Edward Tufte ANYTHING. When I first saw the Napoleon's March poster in his book I had a huge revelation - I started to look at the data being presented from ALL computer programs and realized the difference between data and information.

Note sure where I'm going with this, but I would expect to try to provide some good and bad communication experiences and how communication is the core to successful project management.

When do risks enter a project?

All Risks are present at the conception of a Project
There are no risks that have any potential of occurring that were not present when the project was first conceived. Many risks will never occur and many will never be identified, but they're all there at the conception and will always have some level of potential from that point forward even after the project officially ends. SO - the overall number of risks never increase or decrease over time - what does change is the level of identification, the likelihood of occurrence and the change of impact. A PM's job is to root out the risks that have a high likelihood of occurring that have a high impact and focus the team on mitigating those. The majority of potential risks will never be identified, which in a way is good since the overwhelming number might hinder the team from making progress. Realize the possibility of something happening, keep your eyes open, and move forward bravely.

Take calculated risks. That is quite different from being rash.

George S. Patton

The Whole Enchilada

Ever buy a washing machine or dryer? Often times you'll buy one and then be told that if you want the power cord it'll be an extra charge....what the......?

There is a topic I recently covered at school (Stevens Technology) - Whole Product. Basically you need to determine what the user is expecting and what the team is planning on delivering and determining the difference, making plans to remove the gap of the two. Talk about dissatisfier? How do you explain to your client that to make their $1 million system work, they need to purchase a $2 software package to allow it to run. What would you say?

As we go through developing Projects - the Statement of Work, Description, etc. - we need to understand the entire need and set of expectations and ensure that the project either provides for them or explicitly says otherwise (IN LARGE WORDS).

A Whole Product includes all the pieces to make it work, measure success, communicate about the product, etc - yes a software product NEEDS to include metrics, marketing and post live maintenance IN ADDITION to the product itself. Don't forget to include ALL groups when developing a whole product picture - you'll need hardware or hosting - right? What about the sponsor's needing a way to measure success or audit billing? What about the developers needing post live information to support and maintain the system. List ALL GROUPS, put yourself in their shoes and make sure that what is being delivered provides a complete product.

Watch what you're aiming for

Don't Mistake the Finger Pointing at the Moon for the Moon - Zen

There is a difference between targeting your goals and measuring your progress. You determine where you are, you determine where you want to be and then you set a plan to get there. Along the way you perform various checks to see your progress and health.

Often times people confuse the checks/scales for the goals - they think being 'thin' is a goal, where the goal should be being healthy and weight is one indicator. When people make this mistake they often inflict damage on themselves. Everyone knows about women/girls who fixate on weight - they do severe damage to themselves - here's a disturbing video of it http://www.facetheissue.com/bulimiamovie.html

Isn't it the same for Project Management? (yes, bulimia and those issues are much more critical issues.....just using it as an example). Do we tend to mistake the 'scales' for the goals? A GOOD example is CMM - YES CMM. What was suppose to be, in my mind, a scale, many companies take for a goal. Why would anyone target CMM for a goal? Isn't a goal usually something like customer satisfaction through service and innovative design? Isn't a goal a productive healthy work environment? Isn't a goal something like having a huge market share? What does that have to do with setting a goal to 'Managed Processes'? Isn't that just a determination to how well you're managing? Are you willing to give up customer satisfaction for it?

Let's see....mmmmm..a trade off needs to be made between user satisfaction and 'Managed Processes' - well of course - I'll sacrifice user satisfaction to I can gain more on the CMM scale. If someone said that to me - seriously - and if I had the ability - that person would be gone.

Set goals that provide growth, potential, strength, etc. Let's use tools and scales to determine how were are progressing. Also, make sure that the scales/checks that you are using provide the best feedback. Compare CMM 'Managed Processes' to the Agile Alliance Manifesto of 'Individuals and interactions over processes and tools' . If you want customer satisfaction - what's a better scale? How well your processes are managed or if you're having positive interactions with your customers?

The End Game

At the end of every project that I've worked on, there's a delivery phase. This is an often the most neglected and miss-managed part of the project. Why?

• With the mountain of work ahead, many PM's have to much on their mind to even think about what the end delivery is like.
• By the end of a project, with burnout, turnover, etc. - many teams are not in condition to deliver the product.
• The scope changes, development changes and user changes make the final platform an unknown until near the end of the project.

The project end game include:

• Conversion from an existing platform
• Production environment setup
• Training
• Communication/Marketing (telling people the thingy is available)
• Cut Over - freezing the old and turning on the new
• Pulling the switch
• Monitoring for x hours/days to make sure of performance and stability
• Cleanup - delivery of final specs, training, minor (hopefully) fixes
• PAYMENT! (hopefully)
• Party - no matter how things end up - a cold beer helps decompress
  

When you begin a project you often have a milestone or task that signifies the completion of the project. You SHOULD have a complete section in the plan dedicated to the final delivery hitting all/some of the points listed above. If you don't, then chances are that you're not thinking about it and it's not part of the budget (oops) and a number of unknowns/risks are in your plan.

To understand the end game, you need to put yourself in the place of being live with the system, say on day-x. You need to work your way back (not aways the best thing to do, because that means project time line compression), hour-by-hour and day-by-day and determine what tasks need to be done to get you to the final day-x. What external groups are involved? When do you need to communicate to them by? Are there any additional charges based on their work? Are there any holidays, financial periods, etc. that need to be taken into consideration?

Once this is done, since some back dating of tasks took place, recheck your project and see if the tasks leading up to the delivery phase are impacted, if so they you'll need to move-out the delivery phase to a later date (mmmm slippage - not a good thing).

Right around the time you're thinking about delivery, you should also be thinking about the end results DID THE PROJECT DELIVERY ON WHAT WAS ENVISIONED? Were the success factors met? Time to objectively see where you are, time keeps moving.

Why Matrix Groups don't work

First hand experience and some simple thinking.

I just went through another night of CompanyX/HeavyMatrix had 10 people work from 11pm to 5am moving 2 servers 10 feet. It was an amazing effort that the typical person could have completed within 30 minutes, including a 10 minute pat-on-the-back. The 10 people were from 6 different matrix'd groups - and it just happened that the one person needed wasn't present because 'his group' was not requested via proper channels. SOP for CompanyX.

Let's think about programming for a bit. In programming you have concepts of highly coupled and complete function concepts. Highly coupled relates to different functions/procedures that rely heavily on each other via mass info being passed back and forth and each having to know the other's operating behavior to work properly (something object oriented approaches addresses). Complete function is the same idea - a function should perform a simple/complete/unique operation so as to reduce complexity and cross procedure/function communication. This was an area in programming highly focused on, because it's a known that, HEAVY COMMUNICATION BETWEEN FUNCTIONS INCREASES RISK OF FAILURE. Basic programming understanding that is not yet understood in most corporate environments. Usually each individual function does not fail because of it's internal processing, it fails because of the communication received/sent. Same is true with groups.

Basically, the more the cross team communication, the higher the risk of failure - failure in this case is defined as miss-communication. It's the links between the groups/teams that cause the majority of issues:

• Communication from Users to IT
• Communication from IT to Production
• Communication from Management to Staff
• Communication from developers to QA
• Communication from Analysts to developers
• ETC.

Agile/XP methodologies (mostly focused on development) address this by having complete teams in a single room. Probably one of two (the other being Test Driven Development) MAJOR benefits of Agile/XP. Typical response to having 'complete teams' ie Project focused instead of discipline (QA, DB, etc.) focused. The typical response to complete teams is 'How can we afford to have a team made up of customers, developers, QA, etc. - there might be some slack time - who will mentor the developers.....' The real question is 'If the project is worth it, how can you not do the most important thing to ensure it's success'. The excessive communication required with matrix groups is well documented and known to be exponential.


Development teams like functions in code should be de-coupled and complete - a development team should be a self contained team that can perform a simple/complete/unique project. This is the key to success and addresses the Highly Likely/Highly Impact'ful Risk of miss-communication.

PM Tool Wish List

(taken from ITProjectguide.com)

Wish List - or - Wouldn't it be nice

Project Management is more then tracking tasks - the main focus of Project Management should be building and maintaining relationships and then managing risks. However, many project management tools don't go far beyond task management - and providing pretty gant charts. Here is my wish list of features that a PM Tool would have:

People

Projects are about People and People should be the PM's main project. People include resources working on the project, project sponsors, internal/external influencers, peers, users, resource recruiters, environment support groups, legal, etc. Wouldn't it be nice if the PM tool could:

• Track all people with any relationship to any project and their role to the specific project
• Maintain org charts
• provide personal/public notes about people
• salary/cost (where appropiate)
• basic contact information
• current work load
• associated short/long term tasks
• reviews
• schedule (holidays, class schedule, etc.)

Risks

As Tom DeMarco states - 'Risk Management is Project Management for adults'. Wouldn't it be nice if the PM tool could:

• Track risks, potential occurence, impact, owner, mitigation plan, period when occurence is most likely, etc. (the basics)
• Track est. cost and actual costs to project
• Risk DB that contains risks that are common from project to project (along with mitigation plans, etc.) - in other words patterns.
• Area/Functions/etc. of project that will be impacted

Project Management Basics

All projects have scope, assumptions, constraints, cost/benefit analysis, sponsors, impacted groups, etc. In many cases these are not stated anywhere, or some subset of these are stated and then forgotten. Wouldn't it be nice if the PM tool could:

• Manage Scope, Assumptions, Constraints, etc. - allow and track updates - this becomes a living document (yes 'living document' - nice buzz word)
• Track and manage costs and benefits - adjusting based on project changes and new information is entered
• Perform a comparison between initial and final results, costs, etc. and be able to compare to other projects
• Post Mortem area for project wrap up, things done good, things done not so good, etc.
• Automated process to gain sign-offs for initial project and any updates (routing required docs to the right people for sign-off/approvals)

Requirements/Features

What's a project without something being delivered? Most often requirements are created in MS Word and forgotten about, stories and functioanlity requests are then developed and aged, code is created and bugs are reported. Wouldn't be nice if the PM tool could:

• Track each project deliverable/feature/function from requirements to development to QA and then implementation and maintenance. So a person can look at a specific feature, see where it is in the development life cycle, see all related requirements, see the code, and review any bugs/issues/enhancements reported against it (and their status, etc.).
• Sign-off/Approval processing
• Ability to assoicate prototypes/mock-ups/etc. with each specific requirement
• discussion chain about each feature
• reality indicator - how close the requirements are to what was requested and what was delivered (this would be nice....not even sure how one would start putting this feature together)

Meetings

Meetings, meetings, meetings - what more needs to be said. No one wants them, but we all need them. Wouldn't be nice if the PM tool could:

• Create meeting templates and deliver the meetings notices to the people invited. The templates would contain the standard info such as facilitor, topics, time assoc. with each topic, prior meeting minutes and take away items, outstanding and completed items, etc.
• Ability to take meeting minutes during the meeting.
• Ability to allow feedback to the meeting
• Allow attendees the accept to attend or not and provide them with enough info regarding the meeting to allow them to make the decision
• Video/Audio (IPod?) capture of the meeting - this could be a good or bad thing

SDLC

Software Development Life Cycle - many project managers focus on the project life cycle and do not take into consideration the software development life cycle - the SDLC often lies in wait in the Execution phase of the project life cycle. There are probably more variations to the SDLC then to the PLC....Wouldn't be nice if the PM tool could:

• Track which SDLC is being utilized and populate the required steps, associated risks, etc. based on it - allowing of course for specific variations of the group.
• Provide a status report based on progress, est. work effort, current work effort, est. cost, current costs, etc.
• Provide a dash board to all regarding progress, road blocks, etc.

Bugs/Enhancements

Provide an integrated bug/enhancement management system - Wouldn't be nice if the PM tool could:

• Allow modification to the Bug/Enhancement Life Cycle (BELC) as needed by the group
• Use the b/e information as input to the status of the feature, function, project, etc.
• Allow users to 'vote' on the priorty of the b/e
• Integrate the b/e with the requirements/story

Change

Change is everywhere you look. Change could be to the requirements, the environment, resources, etc. Wouldn't be nice if the PM tool could:

• Track all changes and track the impacts to the project
• Allow what-if scernerios - what if we reduce resources, what if we change scope or delivery dates, etc.
• Feeding changes into the risk plans/mitigation plans

Voice of the Customer!

It's amazing that you can still learn even when you know everything. I've been back at school for about 2 years (or so) now (PM Certificate and Masters) and every so often, if you listen very very hard, you'll pick up new knowledge.

Voice of the Customer! (VOC) - something that most PM's and IT, in general, get chills about. VOC is basically a process of 'listening' to the customer, capturing their requests in their language/terminology, aligning it to what in the project will provide/fulfill the request.

You basically create a grid (MS Excel) with the columns:

• Customer (who the person is and/or group)
• Request (the voice)
• Priority (High, Med, Low)
• Project (what project the functionality, etc. will be provided as part of - if there are more then one project)
• Functionality/How-To - what functionality and/or how will the request be satisfied
• Rating - High, Med, Low - how well did the delivery meet the 'voice'

It may not sound like much, but it puts you in the right mindset to deliver what is being requested as opposed to what you think is being requested. It's also a great way to confirm what the customer is asking for (feedback).

A nice addition to this is adding the 'voice' or management, sponsors, etc., this would provide a complete picture of what is being requested and constraints. Something like:
VP - Sam Sneed - "We need to track who is really using this thingy...." - Report X will do that.

You expand the definition of customer to ANYONE associated with the project. In my opinion, a great PM tool/process.

Leadership

Why do I always picture US Grant in my mind when I think of leadership? Oh - that's right - he was an exceptional leader!

Here's one time I think Wikipedia is a bit wrong in it's definition of leadership:
http://en.wikipedia.org/wiki/Leadership

Not sure who said it, but here's a real definition: Leaders do the right thing right. No more no less. To be a great leader, study them:

• US Grant - maybe he was a drunk - he was a successful drunk
• George Marshall - the MAN behind the winning of WWII
• Raymond Spruance - quiet, direct, devastating
• George Washington - man of honor, willing to sacrifice all and give up power when NO ONE else prior did

In my mind, everyone can be a leader in the role that they play - in the position that they hold. A person needs to understand what a leader is, understand their current role and LEAD. Head of the country or emptying trash cans - understand what you're doing, do the right thing right and you are a leader.

I've seen to many people question leadership, blame leaders for mistakes, work against direction because they gain simple satisfaction. It's far easier to tear down and take apart then to build.

“It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood, who strives valiantly; who errs and comes short again and again; because there is not effort without error and shortcomings; but who does actually strive to do the deed; who knows the great enthusiasm, the great devotion, who spends himself in a worthy cause, who at the best knows in the end the triumph of high achievement and who at the worst, if he fails, at least he fails while daring greatly. So that his place shall never be with those cold and timid souls who know neither victory nor defeat.” - Teddy Roosevelt

How do you become a great leader? Personally, I don't think you can become one unless you are one. If you are one, you need to lead, personally, professionally, morally. Once you start it's hard to stop. There's no class in being a leader, there are books, classes, examples all over how to improve your leadership skills - the most important being biographies of leaders. Learn by example. MOST people lead at some point, keep your eyes open and watch, those moments happen all the time.

Why is leadership important for PM? If a PM is nothing more then a tracker of time and tasks then the money spent on that person is wasted. A PM's value is in the leadership that they can provide. PM's need to set the example, not necessarily make decisions, make lead people to making the right decisions. Not just the right business decisions, but also the right moral decisions.

The time is always right to do what is right. - Martin Luther King, Jr.

Useful Links

There are HUGE amounts of information about project management. Some of the most important ones to me are:

• The Agile Alliance Manifesto: http://agilemanifesto.org this sets the direction for PM.
• eXtremeProgramming - this is where REAL programming and project management started for me: http://xprogramming.com/
• Tom DeMarco - the MAN, if he writes it you should read it: http://systemsguild.com/GuildSite/TDM/Tom_DeMarco.html

There are many more links out there, as I find and/or remember them, I'll list them.

Where to begin?

Why blog? Well, I think I have a lot to say, so let's see. If nothing else it'll be good therapy!

I would like to discuss Project Management, as non-interesting as it sounds, I find it very interesting. I consider it an extension of programming, with the focus on people. To me programming is like carpentry - except you don't bang your thumb physically, it's all about building something, hopefully something important and something you could be proud of.

There's a lot of different names around for different responsibilities in IT: Team Leads, Front End Developer, Database Admin, Database Developer, IA, QA, Business Analyst, etc., etc., etc. When I first got into IT, all I knew were programmers, and they did everything including crawling around under tiles stringing wires around. No matter what I've done, I've always considered myself a programmer....

But that really doesn't matter.

What I plan on focusing on, if I can, is the Project Management aspect of what I do.

What is my definition of PM? PM is the mitigation of RISK! It's all about risk!
Here's Wikipedia definition on Risk - http://en.wikipedia.org/wiki/Risk

To me, Risk is what you confront to get work done. Life is about risk. Programming is about confronting risk while trying to develop a tool.

As Curly once said "Don't look know, but we're about to die"