Project Team Blog

By ExecutiveBrief -online resource on process management, project management, and process improvement.

Scrum burndown charts, or project history charts, as they are called in Standard Time help managers see the time remaining for projects in a line chart.  An example is shown below.  As many know, Standard Time is more than a timesheet.  It contains many project management features like task linking, resource allocation, earned value analysis, utilization percentages and rates.  These can be pretty boring topics unless you need to know where your project is headed.  And then they become pretty valuable tools all of a sudden.  Let’s take a look at the scrum chart.

Notice the falling line chart.  We’ll explain that shortly.

Scrum Chart in Standard Time

The first step to creating this chart is to turn on project history.  Choose Tools, Projects and click a project to begin.  The project properties will display in the right-hand property panel.  Check the “Save task history” checkbox, as shown below.  This forces Standard Time to save time remaining for each project task when hours are entered into the timesheet.  Hours remaining are the raw ingredients for the scrum burndown chart above.

Save Task History in Standard Time
For Burn-down Chart

After turning on the “Save task history” option, now you’ll simply create project tasks and log time to them.  The image below shows a sample list of tasks.  Just remember that each task has a “Remaining” number of hours.  Those hours are plotted on a line graph in the scrum chart.  All tasks are combined to give a snapshot status of your project.  As you log daily time, those hours will fall, until they all reach zero.  Then the project is done!  You’ll see this gradual fall in the burndown chart.  Each week, you’ll notice trends developing.  Hopefully, going toward zero and completion.

Project Tasks in Standard Time

–newshirt

A certain thing happens in product development…  (It used to bug me to death, until I got used to it.)  Your product development team just finishes a great new feature.  Everybody rejoices.  Good feelings, pride, and celebrations.  All that…  The new release is posted on the web, and you start to get downloaders.  Potential customers are giving it a look.  And you know they are seeing the great new feature you just added.  It has “X” and “Y” new things.  Everyone will love it.  Everyone will buy.  You’re sure of that!  Finally… we’ve gotten a great product out there…

The next thing you know, you get an email from an evaluator.  He can’t believe how short-sighted your product is.  In fact, he’s practically indignant.  It’s missing a key feature he needs, and he can’t belive you’d ever consider shipping a product without it.

He asks, “Can you do it?  When will it be available?

“Maybe, next month.  Can you describe it more fully?”

“Oh, I can’t wait that long…  Forget it.”

The situation is that you’ve completed “X” and “Y” but haven’t gotten to “Z” yet.  And that’s what spoiler-boy wants.  Problem is, you never considered “Z” until you completed “X” and “Y.”  Or worse yet, didn’t consider it until he pointed it out.

This is so common.  People cannot see to very down the product road-map.  That’s human nature.  They can see “X” and “Y” but only have fuzzy glimpses of “Z.”  That is, until some grumpy customer complains that it’s not in the product.  He doesn’t see the hard work you put into getting the first releases out.  I.e. getting “X” and “Y” out.  He just sees that “Z” is missing, and feels pretty certain that he can’t do without it.  He’ll move on…  Somebody out there must have it.  “I’ll look around…” he says.

Better get cracking.  Again…

–ray

I’m taking the first day back from vacation to survey my open projects.  I’ve got a video script to write.  And then the video recording, and producing.  The voice-over will occur later.  There’s a product update that includes nothing but maintenance bug fixes.  And a few web site updates.  That’s about all…

Things are really slow.  Reeeeeeeaaaly slow.  I’m guessing it’s that way everywhere.  Our corporate web site gets only half the visitors and one-third the downloads.  Good time to write a short blog.

But think about it…  This really is the best time to launch into some big architectural projects.  After all, nobody’s knocking the door down for product updates.  We have time to rethink things, and retool.  But who feels like doing that?  When nobody cares?

My point?  Economic slowdown has a debilitating effect on product development and project management.  Human beings are motivated by interactions with others, not pure technology.  Product purchases, evaluations, customer demands…  All those intangible things are wrapped up in our management choices.  They are what move us.

–newshirt

CIO Insight did an article listing the top 10 ways to retain IT workers.  The link to that article and results are listed below.  It’s pretty interesting, but appeals strictly to the least-common-denominator or employment.  The results could apply to a landscaping firm.

http://www.cioinsight.com/c/a/Management/How-to-Retain-Top-IT-Workers/

They rated each criteria from 1 to 3, with 1 being the lowest, and 3 being the highest.  Notice that the results have little to do with IT workers.

    Lowest                                                       Highest
        1                               2                                3

    1. Salary: 2.82
    2. Training: 2.47
    3. Incentive pay: 2.40
    4. Paid Time Off: 2.38
    5. Flex Schedule: 2.36
    6. Work Facilities: 2.26
    7. Insurance Benefits: 2.26
    8. Retirement: 2.13
    9. Work at Home: 2.06
    10. Social Environment: 1.99

I’d like to add an intagible criteria to the list: “IT Imortality.”  And I’m wondering where you would place it.  A 1 or a 3?  Send in your comments.

IT Imortality is the chance to rise above your peers in a significant way, building products that change the industry.  It involves working with the brightest and most motivated individuals on the planet.  It means leading (or participating in) a product development team that makes a true impact on your generation.

Although I cannot say I’ve achieved such a lofty status, the lure has certainly been there for every company I’ve worked for.  And, at least a few of my projects have impacted individuals around the world.  That’s offers a sense of achievement that no cubical job can.  I rate that somewhere near 3.

–newshirt

A programmer friend of mine told me that his ongoing maintenance projects didn’t really require the Agile Method.  He said that he liked the idea, but his small team was just working on short, simple updates to an existing program.  He didn’t need a methodology to assist him on that.

We discussed the fact that the Scrum method was light, but still injected some measure of oversight into projects.  But he insisted that his ongoing work needed no such oversight.  He knew what he as doing, and didn’t need a babysitter.

Knowing this guy, I tend to believe him.  He’s been doing C++ programming for two decades, and knows exactly how to get a project done.  But the idea still bothered me.  Isn’t Scrum for everyone?

I believe the answer lies in the size and competency of the team.  Small, highly competent teams, who perform known work, can bypass the methodology.  Just like my friend said, they know what they are doing, and don’t need any “process” help.

But this guy is a rare beast.

Most engineers face a large number of unknowns, and need a simple system to guide the project team to success.  Scrum does that.  If you are unfamiliar with the method, consider getting a little help from these folks: http://www.controlchaos.com/ or these guys http://www.agilealliance.org/

–ray

Has your company developed entirely new software or added to software already in use throughout the organization and found the process cumbersome, frustrating, and sometimes not living up to expectations or meeting organizational goals?  If so, the solution to a smooth and effective development program may be as easy as staffing a well-qualified project manager and adopting a proven development process.

Developing a Practical Approach: The Role of the Project Manager

When undertaking a software development project, the first element to consider is the establishment of a comprehensive yet practical approach to the initiative that ultimately will lead to a successful end result.

The in-house project manager has a key role in ensuring each phase of the project is carried out as planned. The project manager is responsible for considering the potential risks involved with the project and how to avoid and resolve them, establishing and maintaining momentum throughout the project, ensuring individual project team member tasks are assigned appropriately and carried out according to specifications, and successfully addressing and resolving any conflicts that may arise during the length of the development project.

A well-qualified project manager is able to address what may seem to be an overwhelmingly complex process by developing an organized approach where the process is broken down into manageable individual tasks and understanding how to keep those involved in the project dedicated to the ultimate goal of meeting and even exceeding the expected end result.

Embarking on the Initiative: Key Steps to Consider

With a comprehensive approach and a competent project manager in place to guide the new software development initiative, there is another important element your organization may find helpful as you embark on the project: establishing specific steps that can be followed to project completion that are based on proven industry experience in such a project environment.

Two renowned experts, Dr. Gordon Scott Gehrs and Dr. Dorota Huizinga, single out nine key steps to consider as you embark on a software development project:

Step #1: Conduct Feasibility Analysis

Full article, presenting in detail these key practical guidelines to approach a software development project, is available at: http://www.executivebrief.com/article/9-steps-to-a-hassle-free-and-effective-software-development-project/

By ExecutiveBrief: http://www.executivebrief.com

Some of the most common reasons why change requests are made.

Change requests alter the course of a project and working within the constraints of time, budget and quality more challenging. If change requests are not handled properly, the project will overshoot its schedule and accumulate costs that are beyond the original plan.

Realize that change requests are not made because people in your team, the project sponsors, or clients cannot make up their minds. Instead, most requests for changes are made in order to improve the project and, in some cases, the process of implementing the project.

Changes are inevitable during the course of the development lifecycle, and there are various reasons why changes occur. Some of these reasons are technical, some are procedural, some are financial, and still some are political or people-related.  Whether a project manager supports the adjustments or not, it is important to think over why changes are requested and their possible impact on the integrity of the project, as well a the delivery process. Let us look at the most common reasons why changes occur.

Incomplete requirements

Scope changes –or creeping functionality–are the results of ineffective management of requirements.  These are also the results of a project manger’s inability to get approval from project sponsors. When requirements kept going through changes during the course of a development lifecycle, new features and functionalities are often added, resulting in a product that overshoots the allocated time and resources, but fails to meet an acceptable level of quality.

Organizational restructuring

If the client’s organizational structure changes midway through the project lifecycle, it is inevitable for the delivery team to expect either a closer scrutiny of the project or change requests to be submitted. Financial considerations, corporate policies, and new sets of end users are some of the factors to consider as change agents when organization restructurings happen. Some requirements are too rigid, while some requirements need more room for discrepancy in specifications.  When alpha releases prove to be too limited to one set of target users alone, then expect change requests from auxiliary end-users.

External factors, such as new vendors, technologies, or methodologies

External factors, such as the involvement of another vendor or a representative end-user, can cause diversion from the original project execution plan. This issue is often as technical as it is financial (or political). Ideas that are tied to the new vendor’s methodologies and technologies can affect the execution of the project plan halfway through the lifecycle.  Sometimes, clients can be finicky about what they want out of the project that agreed-upon requirements kept getting changed. The more a finicky client gets in contact with vendors who want to take on the project, the more ideas they get about “improving” the product and cutting the cost of development. In such a scenario, be prepared.

By ExecutiveBrief: www.executivebrief.com

�

The early World War I fighter planes had machine guns mounted above the fuselage.  They fired right through the spinning propeller.  That worked most of the time, but occasionally cut the propeller right in two!  I’d call that a bug.

I’ve learned over the years to fix my bugs quickly.  As soon as they are discovered.  Leaving unfixed bugs in a product can result in some nasty consequences.

Suppose you’ve got a small bug that bothers a few smaller customers.  It may not cost you anything in lost sales.  Most people can live with it.  But then along comes a big demanding customer.  When he sees it, maybe along with a few others, he freaks out and decides not to purchase.  You just lost a great sale because of one little bug.  A bug you could have easily fixed.

Moral of the story: don’t cut your propeller in half.

–ray

In my line of business, we often get customers who say, “If your product only had this great feature [that I need] it would really sell.  You’d make a million dollars!”

Such enthusiasm prompts us to run off and produce the requested feature as soon as possible.  And when we do…  Nothing happens.  Nobody’s there to heap praise on us and pay the big bucks.  The product doesn’t sell any better than before, and no such millions are made.  It begs the question: do new features make money?

Certainly from a short-sighted standpoint, the answer is no.  There are no crowds of new customers clamoring for the new feature.  In fact, most evaluators simply take the new additions for granted, and only stop to comment when something they want is missing.  No praise is given for products with great new features.  But lots of crap is shoveled out when something isn’t there.  That’s just normal human nature.

But over the long term, a constant flow of new features that solve customer problems is a good thing.  It builds your customer base and takes the heat off sales and support staff.  View it as a long-term investment that will eventually pay.

– newshirt

Make verses buy: The act of building a product for your own internal use as opposed to licensing a pre-existing product.

Organizations with the ability to produce their own products are often tempted to build everything, including the tools they use.  This is most common with software companies.  They have a bank of software developers, some sitting idle awaiting jobs, and the company is tempted to use those resources to build all the tools they use.

I once worked for a software company that wrote their own compilers and debuggers.  For internal use only.  Yikes!  When Microsoft sells compilers for less than a thousand bucks, this doesn’t sound cost effective to me.

Again, the temptation usually stems from developers sitting around on their hands with nothing to do.  Why not put them to work building internal tools?  My opinion: bad idea - almost every time.  Those developers are saving the company very, very little money.  After all, off-the-shelf software is cheap.  So, divide the number of hours they work by the cost of the software, and your developers are only making a dollar an hour.  Better to put them to work in customer support or sales, cold calling for gigs.

The real killer comes when the software they wrote needs bug fixes and maintenance.  Are those same developers still available?  Usually not.  So who pays for the bug fixes?  You.  Was it still cheaper to write your own stuff?  I doubt it…

–newshirt

Here’s some project management advice: And I’m going to complain a bit…  Hope you don’t mind.  :)  I notice user interface design - especially in software products.  I notice menu placements, dialog box layout, screen widgets, and everything else.  And there’s one thing that always bothers me.

    Complex products seemingly designed for 2% of the intended users - %*^$*#

Developers fall into a common trap: adding too many menus and screen gadgets.  Here’s how it happens…  Sales managers, product managers, and CEO’s all want products to do something new.  Something big and flashy.  Something they can sell.  So, they call down to the developer’s cubes to make it happen.  And it does!  Unfortunately, so do dozens of other feature requests.

Developers often don’t know how to bury the obscure features and highlight the common stuff.  Everything is given equal weighting in the user interface.  That’s okay until you have a hundred big features.  And then everything runs together.  Users see so much stuff, they can no longer gear the product to their own purposes.  It takes a Masters degree to figure it all out.

A better approach is to develop the product for the 98% of customers who will use it.  In other words, MAKE IT SIMPLE!  Bury the features intended for the other 2%.  That doesn’t mean you’ll only bury 2% of the menus and dialogs because normally about 50% of the product falls into the “obscure” category.  Bury all that, and explain it to the 2% who need it.

–ray

Have you ever used a scrum burn-down chart?  Funky name, huh?  It’s actually a pretty handy line chart.  The image below is an example from Standard Time®.  There, it’s called a project history chart.

On the X axis, you see time (weeks, months, quarters).  On the Y axis (vertical) you see the number of remaining hours for your project.  As work is applied to the project, it burns remaining hours down to zero.  Team members can see the downward trend and predict when the project will finish.  This is the “light at the end of the tunnel” chart that helps people push for completion.  Show this in your scrum sprint meetings, and your team members will take heart.

Scrum Burn-Down Chart

 As you can see, there are some up-ticks as well.  Those represent project scope changes.  Some bright individual decided the project needed a slowdown, and added some additional tasks.  Do that at your own peril, because this chart shows all.

–ray

Project management advice: Every project needs a champion.

It took me a while to understand the nature of product development and the need for project champions.  At the beginning of my career, I believed projects just “got developed.”  I was working in a research department at Eastman Kodak Company, building cutting edge photocopiers.  Engineers buzzed around, building microprocessor-based circuits, image-enhancing emulsion, and writing software.  I did my part and just expected the product to come together.  Looking back, I now realize there was one man who made it all happen: a gray-bearded old dude who wanted to change the industry.

Products get developed, and projects finished, only when there is someone with the burning desire to see it happen - like the old bearded dude in the example above.  A paycheck is not enough.  You have to want it badly.  Only then will you fight through all the obstacles to make it happen.  Projects often take 2-3 times their original estimates, and some required several iterations to realize the full glory.  And only a true champion will endure the suffering to see it to completion.

Look around at your project.  Do you have a champion?  A person who refuses to give up?  If not, you have good reason to fear that the project could be canceled or back-burnered.  Have you personally ever been a project champion?  If not, give it a try.  Throw yourself into something that really engages your passions.  You’ll find there’s satisfaction in a job well done.

–newshirt

Feature Creep: Small product feature additions that unexpentantly expand a project scope.

Feature creep is one of the big reasons projects ship late.  Some people simply cannot deny themselves.  They want more and more features in their great new product, and can’t stop adding them  Here’s how it happens.

When a new product feature is complete, there are oohs and aahs from all the project stakeholders.  They love it!  Why?  Because they are sure customers will find it useful and reward the company with more business.  That’s only natural.  But then something else happens…  One of the stakeholders steps up and says, “That’s cool, but can it do one more little thing?”

All the other stakeholders agree.  The new feature you added is nice, but the product should do one more thing to be complete.  And they may be right.  So you add that.  And a few more things.  And a few more things after that.  That’s feature creep.

Little additions creep into your product features until they consume a major part of the project timeframe.  The extra features are nice, but can you afford the extra time?  After all, you now have less time to implement all the other cool features you were asked to do.

Stakeholders often don’t understand this problem.  Later, they’ll come around and ask why your project is behind schedule.  You can’t say that it’s because of all the little things they asked for.  Why?  Because they won’t remember those or they don’t see them as a major time sink.  See the problem?  You can’t win with feature creep. 

–ray

Every company needs specialty tools to make their company run - little things to help make things easier.  For example, a cabinet shop might need custom-built jigs.  An auto mechanic may build a few of his own tools for jobs he performs frequently.  High-tech companies certainly build plenty of in-house programs to manage information technology - databases, data entry, customer records, etc.

The question I’m posing is this: when is it right to build those custom tools in-house, or when should you go out and buy a suitable tool instead?  For instance, should an auto mechanic build his own 500 piece wrench set, or go down to Sears and buy them?  Should a tech company build a time tracking product from scratch, or license something like Standard Time®?

Since I’ve personally worked in consulting for a number of years (in another life), I’ve seen it all.  I’ve seen companies build products that were available off-the-shelf for 1/100th of the cost.  And, I’ve seen people shoehorn freeware code and products into commercial use.  Both were mistakes.

I tend to say that companies should only build products that are much more expensive to buy.  In other words, don’t try to write your own compiler - Microsoft does that just fine.  Another reason to build is when you have exotic business needs.  One last reason might be if you have time on your hands.  If you’re not making money serving customers, maybe you’ll have time to write and maintain a few necessary tools.  But that’s a dangerous position to be in.

In IT, we ignore such advice because we know we can build everything.  But I suppose the mechanic with a little metal-working and welding experience does the same thing. 

What tools have you built, and regretted it?  Post a comment and let me know!

–ray

Have you seen the Channel 9 interview with Bill Gates?  The link is below.  The interview is about a half-hour long, and focuses on Gate’s plans for the future as he transitions out of Microsoft and into his philanthropist foundation to help the poor.

http://www.microsoft-watch.com/content/corporate/a_month_of_gates_7.html

Here are some quotes I found interesting.  These are the kinds of lines that drive my own thinking.  They drive me to fight for our brand position in the marketplace.

You’ve got to have product plans for every product you expect to release in the next few years.  And those plans have to be very realistic.

 Making sure we take some risky bets.

We are a very self-critical culture.

Software seems to be so complicated…  Software has some composability today…  But we have to make it easier to write big software.  We’ll have a lot more progress in the next decade.

 It’s always surpring to me there’s little attention paid to what we are doing for business users.

We care about the information worker.

We’re always sharing about where were going so people can make plans.

Best of luck, Bill.  Care to comment on the Channel 9 interview or this humble post? 

–newshirt

Ever wonder why there are so few product-based companies, and so many service-based ones?  It’s all about cash flow.  The images below illustrate this, but they need some explanation.

Product-based companies
If you’ve got bright ideas of building a product and making lots of money, think again…  There’s a long pipeline from product development to big piles of sweaty cash.  First, you have to build the product.  Nobody’s paying you to do that.  It’s your nickel, pal.  And you can spend as much time as you like.  But then comes marketing and promotion.  Get it out there for the world to see - but still more time without pay.  And then, when they find your product, you’ve got to sell it and collect your reward.  It can take months or years.  And it can be exhausting.  See the stages below.

Service-based companies
Want cash quick?  That’s why there are many more service-based companies in the world.  In that model, you can find a client and begin invoicing them after the first thirty days.  The path to that stack of sweaty cash is much shorter.  But, the stacks are smaller.  And, you tend to live on them so they never accumulate.  Lose a client, and you’ll have to start over.  Even this model has it’s risks.

So which model suits you?  Got the time of invest and wait for the “big” payoff?  Or, do you prefer earning as you go along?  There are plenty of advantages to both, and only you can decide what’s right for you.  Hopefully, this short post will help in your decision-making process.

–newshirt