Why Foundational Features Matter

Let’s say you know customers need a really complex feature, but your project team only has time for a basic implementation.  Do you wait until you have team resources to build the full implementation?  Or do you just build a basic foundational product that doesn’t actually meet any current customer requiments?

My answer: Start with the basics.  Add later.

Foundational product features are usually enough to sell the full implementation.  Customers can see that you have a percentage of what they need.  That helps them have faith in a full implementation at a later time.  They know it’s just a derivative of your current implementation.  But without something tangible to demonstrate, they won’t believe you’ll do the feature at all.

Phased Product Releases

What do you do when you find yourself in the middle of a deep product feature hole?  I’m talking about developing a new feature that you find is taking four times as long as you originally thought it would.

For project managers like me, panic sets in…

Here’s why: Having the product readily releasable is the absolute highest priority.  Deep dives jeopardize that.

So here’s what I’m going to do for this particular feature.  Reluctantly, I’m going to release it over four product releases.  Here’s how I’ll phase it out:

        1. Database plumbing (already released two weeks ago)
        2. Middleware, or business logic plumbing (next week)
        3. Basic feature functionality (a while later)
        4. Full feature functionality (a bit later yet)

–newshirt

U.S. Losing Competitive Edge in Technology

The recent eWeek story regarding U.S. decline in science and technology (see below) is nothing new.  We’ve heard this same story for twenty years.  But is anyone listening?

http://www.eweek.com/c/a/IT-Infrastructure/US-Losing-Competitive-Edge-in-Technology-Science-National-Science-Board-610257/

Over the Christmas break, I did my bit to encourage passion in software development, engineering, and project management.  I mentored a college student with an Arduio board.  (See http://www.arduino.cc/)  The Arduino is a microcontroller with inputs and outputs for controlling external devices.  It’s big in university engineering departments.  Awesome, dude!

We stayed up past midnight wiring circuits and slinging C++ code to exercise the Arduino I/O ports.  In a rat’s nest of wires, LED’s flashed, speakers squealed, and relays clattered.  Cool!  When it was over, the kid had a new passion for product development and engineering principles.

Code ‘til you drop, and then do it again tomorrow!  That’s my answer to declining technology in the U.S.  And I suppose it’s also my preferred project management style.

Small Bites

I like keeping project tasks really, really short.  A week-long task is sometimes too long, but obviously satisfying when finished.  I also like keeping product releases very short.  A release might have only a few of these short tasks.  That ensures that the product is always within a few days of release.  Project scheduling is simpler when tasks are short.

7 Things You Need to Know About Development Project Estimations

Whether you are a project manager planning for a smooth implementation of a plan or a project sponsor on whose decisions a project depends, you cannot escape from the fact that project estimation is essential to its success. In the first place, there are three basic requirements that a project must satisfy: schedule, budget, and quality. The need to work within these essential project boundaries poses a huge challenge to everyone in the central management team.

There are various aspects that affect project estimates, such as team skills and experience levels, available technology, use of full-time or part-time resources, project quality management, risks, iteration, development environment, requirements, and most of all, the level of commitment of all project members.

Moreover, project estimations do not need to be too complicated. There are tools, methodologies, and best practices that can help project management teams, from sponsors to project managers, agree on estimates and push development efforts forward. Some of these include the following:

  1. Project estimates must be based on the application’s architecture. Making estimates based on an application’s architecture should give you a clear idea of the length of the entire development project phase. Moreover, an architecture-based estimation provides you a macro-level view of the resources needed to complete the project.
  2. Project estimations should also come from the ground up. All estimates must add up, and estimating the collective efforts of the production teams that work on the application’s modules helps identify the number of in-house and outsourced consultants that you need to hire for the entire project, as well as have a clear idea of the collective man-hours required to code modules or finish all features of the application. Ground-up estimates are provided by project team members and do not necessarily match top-level estimates exactly. In this case, it is best to add a percentage of architecture-based estimates to give room to possible reworks, risks, and other events that may or may not be within the control of the project staff.
  3. Do not forget modular estimates. Once you have a clear idea of the architecture, it becomes easier to identify the modules that make up the entirety of the application. Knowing the nature of these modules should help you identify which can be done in-house or onshore, or by an offshore development team. Moreover, given the location and team composition of each development team that works on a module, it becomes easier to identify the technical and financial resources needed to work on the codes.
  4. Development language matters. Whether the development language is Java, .Net, C++ or any other popular language used by software engineers, team that will be hired for the project must be knowledgeable in it. Some development efforts require higher skills in these languages, while some only need basic functional knowledge, and the levels of specialization in any of these languages have corresponding rates. Most of the time, the chosen development language depends on the chosen platform, and certain platforms run on specialized hardware.
  5. You cannot promise upper management dramatic costs from offshoring. While there are greater savings from having development work done by offshore teams composed of workers whose rates are significantly lower from onshore staff, you must consider communication, knowledge transfer, technical set-up, and software installation costs in your financial estimates. Estimating costs is often more about managing expectations, but as the project matures, it should be clearer whether the money spent on it was money that was spent well.
  6. Project estimation software and tools help identify “what-if” scenarios. Over the years, project managers have devised ways to automate project schedule, framework, cost, and staffing estimates. Some estimation applications also have sample historical data or models based on real-world examples. If your business has a lot in common with the samples in the estimation tool, it can help you identify what-if scenarios and in turn include risks, buffers, and iteration estimates.
  7. Price break-down helps in prioritization. Breaking down the total cost of the project helps management decide which parts of a system should be prioritized, delayed, or even cancel. Estimating costs for a new project may not be easy, but project sponsors and managers must be able to know and agree on the breakdown of costs of development, technical requirements, and overhead.

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

How to Create a Scrum Burn-Down Chart in Standard Time

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 Burndown
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

The X, Y, and Z’s of Product Development

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

New Years Projects

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: How to Retain Top IT Workers

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

Use Agile Method for Ongoing Maintenance?

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