C-Amx

I had two software projects to specify, document, design, develop, test and get ready for commercial sales in a 3-6 months window with a very limited budget, a staff with very low morale and very desperate investors. I am called in to fix a rather typical scenario: cost overruns / year(s) behind schedule. They have been unsuccessful at releasing any software for the last three years; - My resources consist of four programmers in Norway , ten in Russia and three in Toronto . I am already facing three obstacles before I say ‘start':

The time difference between countries is a management and coordination issue. (not good)
I am their superior and I was brought in by management. Moreover they know nothing about me and they are programmers. (If you ever worked in the Tech industry, you know exactly what I am talking about)
The physical lack of presence of most of my staff kills any idea I may have had to charm them by my new suits or by my personality.

So, I have very defined goal, (two actually) but not one that I can assign my staff to accomplish without a very strict roadmap. Besides, programmers like engineers have no sense of business time and their interest in the business aspect of what they do for a living is almost immaterial to most (Mostly I believe because they are seldom made to participate). In order to set my goals, share them with my programmers I need a lot of luck or more prosaically a project management method that is simple, has a built-in control mechanism (as in what is happening now and why?) and that is very clear to all.

From day one, I had to set goals for the company, myself and my team, so I developed a special methodology in order to set short term goals to make the end goal attainable. Most people get dizzy, sick and frightened when you make them look too high up and tell them you want them on top of this mountain in a few months.

> Objectives: Get the work done on time and on budget, by setting attainable goals: How to set and attain my Goal? It seemed totally hopeless until an old philosopher came to my rescue. He murmured ear: “If you have a very long trip ahead of you and you have to get there without much food and in a short amount of time….”he paused, then resumed “and on top of that you have to convince other people not only to go there with you, but to do most of the work for you to get there….well, you are in a little bit of a mess, kid…” He looked at me with amusement, and abruptly said: “The solution is in The Method”

I said what? The what? But he kept on repeating “yes, the method, just follow the method”. A tight grip on my forearm he continued “yes a very long trip it seems, but just divide each portion of your journey into shorter trips, and continue dividing these short trips into shorter ones until all you have left to travel are little walks, simple little walks, which all added together will get you there… little man”.

That night till late unto the next day I wrote a goal-setting methodology that was elemental- task-oriented, applied to scheduling. I spent two days with my team going over the Method, explaining theory and practice of how to get to our goal .

To apply my theory of elemental task-driven scheduling , the whole team participates in the ‘task breakdown process' which we have seen consists of identifying all elemental tasks, or in other words, identifying the lowest self-referential unit of programming. Only one person in the end can divide and assign the tasks (into a schedule and assign to each member of the team) otherwise you will have multiple schedule and you might as well not even start.

You need practical rules to implement and follow to make sure the theory gets set into practice to reach the overall goal (finish software in time and on budget).

The goal then becomes a lot of little goals that are set to organize the work. These sub-goals are defined in space as Tasks and in time as Schedule

Explanation to the programming team: this is what I said and how I applied the rules:

“I need all of you to follow the full and rigorous implementation of this method throughout our development schedule. It is essential to do so for this project to be successful. This method is task driven . This means that each programmatic task is a small unit of functionality, what we call an elemental task, because it cannot be broken down into other sub-tasks. As such, a single task will always have the following attributes:

The Task has its own reference ID number: If this task is referenced (In code documentation or any document) this particular task ID number will appear on all documentation and templates (and placed in the our code data repository) This ID is on your project schedule (see picture 1)

The first column on your right, before the task name is the task ID > The Task assignment form template document that will contain the task ID for code documentation is in the Source Repository

The Task is self-contained (constitutes one precise action) It will be unique in the action it describes and deploys
The Task needs one programmer only
The Task will not be concurrent to another task by the same programmer
The Task is delimited on the outside by time and budget constraints
The Task is delimited on inner boundaries by policies/rules/memberships to other “tasks”
The Task is resources dependant (If you require resource and material please make your case)
The Task is assigned a resource, a start date an end date and a milestone (deadline of group of interrelated tasks)
The Task has a unique task name and its own resources
The Task has a unique timeframe
The Task is published in master project schedule server every Friday with updates if necessary
The Task is fully documented as per template document (see below – picture 2.)

In a task-driven programming environment, the Project Manager will issue all tasks. One task is assigned to one programmer who will be held responsible for delivery according to project schedule

The project manager is responsible for assigning and reviewing tasks
ALL task-assigned programmers shall give me an update status every Tuesday and every Thursday and review schedule with me.

Unit testing has been done
If required, regression testing has also been done (tested against the existing system)
Task is documented (see below)
Source code is IN SourceSafe after successful compile
You are ready to start the next task immediately

The purpose of this form is also detailed and explained in another section of the site. It can be downloaded from the “White Papers” page.

Task ID Number	(taken from schedule)
By	(Author)
To	(All concerned)
Date	Date issued
Subject	State document purpose
Approved By	(If sign off required)
Sign Off	(If sign off required)
Sign Off Date	(If sign off required)
DocName	(document name is)
DocLocation	(document is saved on network or shared drive)
Assignation(s)/ Role(s)	(Personnel directly affected by the content of this document)
Target Date	(realistic assessment date of completion)
Objective(s)	(what will be factually accomplished)
Goal(s)	(How it will be accomplished: Gather all aggregate or block elements that must be assembled or achieved to get to the objective)
Directives	(Divide and re-divide all goals into small indivisible and basic/simple steps needed to create an goal)
Schedule	(Timing involved in each directive)
Memo	(Additional information)

Results: Set goals as directions . Goals should be expressed/explained in no more than one sentence. Always know where you are and where you are going and make sure your team knows it too. Always set attainable goals for yourself and your team. Failure to accomplish the above will eventually lower productivity, job satisfaction, and most likely make you fail your deadlines. The success of this particular method ( elemental task-driven scheduling ) as a goal setting methodology has been successful in three out of four of my recent projects. The fourth project, due to its nature, needed a radical new approach. I have detailed this in another section.

Scheduling meetings (highly important) as outlined and the elemental task-driven approach were a big success if we judge it by its rapid absorption, the staff's dedication to it and the quality of documentation that was delivered to me according to the Method. Such high level of documentation is rare and will be extremely useful to the future of the products (along with the source-code) as it will show and explain the logic behind the code. Future programmers that will work on these project will gain a lot of time understanding why the code is written the way it is and will be very appreciative for it, maybe just as appreciative as two of my own senior programmers who told me I was the best Project Manager they had ever worked with (probably had not worked with many…).

	>>>>> www.lesliemelcher.com
	Home