Posted on

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

Posted on

Define: Material resource

Material resource: A non-human, quantifyable substance assigned to project tasks.

Material resources are assigned to project tasks, but are not human resources.  They are any quantifyable material used to complete the task.  The image below illustrates.  In this example, 40 yards of sod are used in completing the “Lay sod” task.

–newshirt

Posted on

Daily Scrum in 1910?

Warren mentions Henry Gantt’s desire to update project schedules daily (see post of Dec 27, 2011 http://www.projectteamblog.com/?p=190).  He met with his team daily!  I find that refreshingly visionary.  Gantt is seeing a hundred years into the future, and doing things the right way.  He’s staying on top of things in his own 19th Century way.

Sure, Gantt’s daily meetings were not the same as a Daily Scrum meeting — Scrum is not a warmed-over Gantt chart.  Gantt was simply reminding his team of the project schedule and tasks ahead, and updating his new-style chart to reflect the conditions on the ground.

That effort alone — the daily meeting — probably accounts for 75% of the success of any project.  Three cheers for Henry Gantt — 1861-1919!

 

–newshirt

Posted on

How to use Overtime in MS Project

Admittedly, overtime is a clunky feature in Microsoft Project.  I like the simplicity of Standard Time better.  But here are some steps to help understand and master overtime usage in MSP.

Start by assigning resources to your tasks.

  1. Right-click in a column header
  2. Choose Insert Column…
  3. Insert the ‘Resources’ column
  4. Enter names for employees that will work on each task

Assign cost rates to resources

  1. Choose View, Resource Sheet
  2. Enter currency rates for ‘Std.’ and ‘Ovt.’

Enter overtime hours

  1. Choose View, Task Usage
  2. Right-click and insert ‘Work’, ‘Cost’, ‘Overtime Work’, and ‘Overtime Cost’ columns
  3. Enter hours for the Work column
  4. Enter a portion of those hours that will represent overtime work

You will notice that the ‘Duration’ value shrinks for tasks with overtime hours, and that the ‘Cost’ and ‘Overtime Cost’ values are update accordingly.

 

–newshirt

Posted on

Predictive Analytics

Predictive analysis uses historical records to predict future trends or outcomes.  That got me thinking; could that be applied to timesheet records?  The most common field for predictive analysis is credit reporting, where lenders hope to predict a buyer’s ability to pay.

Do you have a 900 credit score?  Me neither…

So, back to timesheet data…  What could we possibly learn from predictive analysis of timesheet records?  Here are some possibilities:

  1. Cost and duration of certain projects in your portfolio
  2. Employee contributions to strategic projects
  3. Typical project contribution histogram overlaid on today’s projects

–newshirt

Posted on

Why is it called ‘Waterfall?’

Warren has been expounding on project management methodologies lately, so I figured I’d throw in with him.  Consider this explanation of the ‘Waterfall project management model.’  It might be useful to some.

Here goes…

Why is the old project management model named ‘Waterfall?”  What, exactly, does that mean?

I believe the term stems from the notion that water falling over a dam is hard to scoop back up to the top.  Virtually impossible, one might argue.  The term ‘herding cats’ comes to mind.

So how does that apply to project management?

In real life, some projects are like that.  Not all, but some.  Consider building a skyscraper, for example.  You absolutely have to get that foundation right the first time, because you cannot go back and work on it after the ironworkers have laid a million tons of infrastructure on top of it.  In other words, reworking the foundation would be as hard as scooping up water that has already fallen over the Hoover Dam.
But are all projects like that?  How about software?

No.

Software is malleable.  You can work on any part at any time, even after the product ships.  So the Waterfall model doesn’t apply as neatly.  Or at all.  But it’s still applicable to certain projects where it’s hard to rework ‘foundational’ stages.

–newshirt

Posted on

My list of project risks

There are at least a hundred reasons projects fail.  Expect anything from vague requirements to budget shortages to waning passions to unreasonable project schedules.  All novice mistakes…  But we can’t all be experts on every topic.  About the best we can do is identify the most common areas for failure, and discuss these with the team.  At least the team will be aware.

Here’s a quick starter list.  You’ll probably have to make it a little more diplomatic before presenting it to your group.  “:)

1. Newbies don’t know how long things actually take.
2. Unfamiliar technologies need extra research time.
3. Virtual development teams don’t communicate the same as in-house.
4. Team members without a passion for the product won’t perform.
5. Vaguely defined projects either go on forever or burn up in debate.
6. Projects without top-level commitment get lost in the minutia.
7. If the company doesn’t need it bad enough, it will fail.
8. Pick only two: Cost, Quality, or Time.  Let the third fall where it may.

–newshirt

Posted on

Time estimates are tricky

If you are an inexperienced project manager, engineer, or designer, consider tripling your initial time estimates for projects.  That’s not a slam.  It’s just that new managers don’t take a lot of minutia into consideration when developing project time estimates.  Experienced people have been through a lot of project cycles.  They have seen a lot, and the know the hundreds of little things that can bog a project down or extend it long beyond all normal estimates.  So if you’re new, triple the schedule until you know the details.

Posted on

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.

Posted on

Success Factors in Knowledge Management

Knowledge management professionals must keep in mind that KM’s explicit end-goal is profitability while its implicit purpose is to empower participants through intellectual platforms and processes that promote learning and practical knowledge.

Knowledge, without a doubt, plays an important role in the success of any organization. In fact, in order to maintain a competitive advantage, modern organizations incorporate knowledge creation, knowledge sharing, and knowledge management into their business processes. The mere survival of many organizations hinges on the strength of their capabilities; moreover, companies form decisions based on their relevant knowledge of their business landscapes.

Thanks to developments in information and communication technologies, it is now easier to develop, store, and transfer knowledge. This capability is particularly true among organizations with global workforces. After all, international competition and globalization are the driving forces behind most technological innovations, and companies quickly take advantage of these developments when it comes to managing the creation and flow of information.

“Ultimately, leveraging relevant knowledge assets to improve organizational performance is what knowledge management is all about,” says Murray E. Jennex in his book, Knowledge Management in Modern Organizations (2007). However, in spite of the lightning-speed creation of new knowledge and the improvements in communication technologies, many organizations still find that their knowledge management practices are lacking. Specifically, within client-consultant relationships, knowledge transfer does not always translate into better performance by all project team members, nor does it always translate into the successful delivery of projects.

To be successful, knowledge management programs require more than simply conducting training sessions or transferring knowledge. Practitioners must always remember that KM’s explicit end-goal is profitability – while KM’s implicit purpose is to empower participants by providing them with the intellectual platforms and processes that promote learning and practical knowledge.

Here are a few factors that contribute to successful knowledge management initiatives:

  • Linkage between knowledge and economic performance – Knowledge management exists because it enables the organization to reach its business goals. Otherwise, there is no point in putting together all the best practices, tacit knowledge, and skill sets in a cohesive system that is accessible by all parties – when and where they need it. As business increasingly becomes more global, the competition for greater market share depends on the capabilities of its players to a certain degree. KM practitioners must be able to identify the business value of knowledge management in their organizations – whether it is to manage projects, provide back-office operations services or to give ideas on how processes can be better optimized – among others. In most consulting relationships, knowledge is the currency by which all transactions are made.
  • Setting and communicating clear objectives for specific organizational or project levels – Heather Kreech, the Director of Knowledge Communications of the International Institute for Sustainable Development has some specific ideas on this very subject. In her paper, Success Factors in Knowledge Management (2005), she states that knowledge-sharing works best when knowledge managers “gather and communicate knowledge at the project/activity/field level before [they] begin to aggregate up to corporate systems and general knowledge marketing strategies”. Having a specific organizational level or project group in mind, results in better designed knowledge management systems, training programs, and tools that can meet the specific needs of workers.
  • Having the appropriate systems and infrastructure – Ideally, knowledge is created, processed, stored, and archived. Managing the process of creating knowledge, communicating this knowledge to participants, and making knowledge available to anyone in the organization, means that an organization must have the right communication systems and data storage facilities. However, it is not enough to simply store knowledge as this knowledge must be found whenever it is needed. Thus, the availability of internal search facilities and computer-based training programs is critical.
  • Having the right champions – KM initiatives need project and process champions who can rally the support of everyone – from top management down to individual staff members. Having management support can result in the freeing up of resources – such as financial, expertise, and infrastructure – all of which are critical to the successful implementation of KM projects. Financial backing means that KM managers can implement training programs, hire both internal and external specialists – as well as acquire the required infrastructure to manage training programs. On the other hand, access to experts from either within or outside the organization, means better identification of knowledge gaps and training requirements, and more importantly, engineering training and communication programs that meet the said needs.

By ExecutiveBrief
Technology Management Resource for Business Leaders
http://www.executivebrief.com
¼/p>