Project Team Blog

Project management advice: People don’t like to be led, especially professionals with clear responsibilities.  Nobody likes “a person who knows” to tell them what to do next.  All the time.  It’s demeaning and annoying.  So what’s a project manager to do?

Clearly, project managers and leads need to stay a few steps ahead of team members.  If they don’t, projects go astray.  Why?  Because it takes time to formulate a clear vision, one that won’t break down in the face of life’s challenges.  Only by staying ahead of the team can the leadership maintain that strategic edge.  But it’s when that strategic direction turns into tactical dictatorship that things go badly.

Some managers have such a hard time articulating their vision that they resort to dictating exact tactical steps to achieve it, rather than relying on competent people to pull it off.  See the issue?  It’s a difficult balance.

–ray

When undertaking a software development project, an effectively designed closure plan serves as an outline of required tasks that must be carried out appropriately in order to result in successful project delivery, and adequate preparation is one significant element when it comes to ensuring a smooth transition to implementation. The closure plan must be considered at the outset of the project, as the client outlines their specific software requirements. With a detailed description of the desired end result communicated and understood, the expected capabilities and deliverables of the software are established. But as you enter the final stages of a software development project, what can be done in order to ensure that the program is completely suitable and fully primed for implementation?

Key Components
According to Joe Coley, independent software developer and member of Northeast Dataflex Consortium, “Projects that I’ve been involved with…have been very much subject to additional needs and desires of the user community.” In effect, this means that the end deliverable becomes the focus of the closure plan — that is, to ensure a high level of end user satisfaction with the software requested and therefore created. Coley has 20 years of experience in the information technology industry and offers much insight on the subject. When it comes to key components for successful closure plans, he highlights three main aspects to consider:

• Assess the project requirements. In order to determine the best course of action throughout the cycle of a project, it is necessary to first consider the scope of the project. Establishing a clear outlook and complete understanding as to the required deliverables will greatly improve the ability to adequately determine exactly what tasks must be carried out in order to meet these deliverables in an efficient and timely manner.

• Communication. While communication is always essential throughout the cycle of any project or initiative, it is imperative to establish a specific plan for obtaining end-user input, as needed and where feasible. Therefore, a key component to a successful close is establishing and maintaining open lines of communication with the appropriate groups. The end users comprise the group of those who will be utilizing the software in real-time business applications; they have the critical business knowledge as to ways in which the software can be created or functionality that can be incorporated so that the result will be a valuable tool with the capability to enhance their business functions.

• Offer continuing support. When it comes to considering a focus on the continuing support needs of the end-user community, Coley cites a specific reason to do so, “There is always an expectation of continuing support in the form of application tweaks, bug fixes, and enhancements.” By extending continuing support to the end users, they have more confidence in the software program as well as in their chosen developer.

Full text of the interview with Joe Coley is available here: http://www.executivebrief.com/article/the-beginning-of-the-end-defining-project-closure/.

The company I work for is located in Colorado.  And for recreation, we climb mountains.  While climbing one, it occurred to me that you can’t always see what’s over the next one.  There are plenty of obstacles to block your view.  Maybe the next one will be easy.  Or maybe it will kick your butt.

Running a business is like that.  At startup, you’re anxious and ready to go!  You take each hill with blind ambition.  Nothing seems impossible.  You see a few mountains on the horizon, but feel certain they’ll fall by the time you reach them.  But the things you can’t see nag you.

A few years into the endeavor, and you are sure it’s licked.  But you really don’t see anything beyond the nearest hill.  Some of your biggest obstacles are yet to come.  And you don’t even know it.  That’s when you need the real stamina.  And the faith to push up that next hill, however high it may be.

What are some obstacles your fledgling business might encounter?  How about this nasty list:

1. Well-entrenched competitors
2. Market changes
3. Economic downturns (remember the dot-com bust and financial meltdown?)
4. Personnel loss

They say 80% of all businesses fail within 5 years, and 80% of those remaining fail within the next 5.  Who’s they?  I don’t now, but my little startup is nearing year 9.  Does that make it better than 96% of the rest.  Well maybe, but I still feel like we’re just wandering in the mountains like everybody else. 

–newshirt

While SaaS has been gaining popularity recently, it is remarkably noticeable that its popularity is still limited mostly to small and medium-size businesses. Larger enterprises are still reluctant to embrace hosted application for their IT needs.

According to a recent Forrester Research paper, “The Truth about Software as a Service,” which is a result of a late 2007 survey of IT decision-makers from North America and Europe, only 16 percent of respondents are using SaaS applications. On the other hand, 80 percent are still reluctant to adopt SaaS. Of the 80 percent, only 47 percent expressed interest, while 37 percent were “not interested at all.”

If SaaS has been gaining popularity recently, the gap between big-business IT decision-makers who were interested in it and those who were either partially interested or totally uninterested is too wide.  As if to counter the SaaS advantages that were cited in the previous blog, researchers and tech workers in big enterprises cite various reasons why it is not being widely adopted outside the realm of SMBs. 

One of the top reasons why big businesses are reluctant to adopt SaaS is business continuity. Put simply, the market’s atmosphere is fraught with uncertainty that SaaS vendors could just shut their doors easily. When it happens, where do the hosted data go? What alternatives are immediately available to end-users?

Next to business continuity, data security, vendor lock-in, and accountability are some of the issues that clients — both large and small or medium-size businesses — raise most of the time. Because many large enterprises are sensitive about their company data, they are reluctant to hand company information to third parties. In terms of accountability, there have been complaints about vendors’ dishonesty about real downtime rates and the speed with which they address it. If a service is suddenly cut off, IT departments ask how long it takes for the service to be available again and what kind of assurances are provided to address such issues.

SaaS are typically fit-for-all, so customization is another nagging issue. Maybe small businesses’ IT needs are not complex, that is why they are more willing to sign up with SaaS vendors. On the other hand, enterprises that provide more than one type of service, sell more than one product, are present in different locations, and employ thousands of employees have IT needs that are as complex as their multinational presence and multiple businesses. That most vendors do not offer customizable services to match big businesses’ needs is one of the signs that it is still in its infancy.

Related to downtimes is the issue of scalability. Can a hosted service support thousands of users who access the application simultaneously? If it cannot, can a business enlist the help of another vendor? This is where the issue of interoperability and portability also come in. In most cases, transferring data from one SaaS provider to another takes time and considerable effort.

That SaaS became popular among SMBs means it is promising. However, this promise does not translate well in big business so far.

By ExecutiveBrief
www.executivebrief.com

Yes, there’s actually a “day” for project managers: November 6th, 2008.  See the link below for more information.  Here’s a little teaser quote from the web site.

http://www.internationalpmday.org/

The international project management day is intended to encourage project based organizations worldwide or organizations who utilize project management methodologies to schedule some type of recognition event within their organizations or coordinated locally with others to truly demonstrate appreciation for the achievements of project managers and their teams.

My job is more than just project management.  I oversee operations and projects.  I perform project planning, and do lots of project management.  I even write a little code from time to time.  My gut feeling is that most folks wear several hats these days.  Project management is only one of many.  But those many things can lead to distraction and bad projects.

An organization like this pulls us back into the discipline.  Back into the bedrock rules that make all successful projects work.  That’s a good thing.  If you haven’t registered for allPM’s webinar, here’s a link to do it!  http://www.iil.com/ipmday2008/webcast.asp

–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

Why SaaS may be the next wave in enterprise computing.

Much has been said lately about Software as a Service (SaaS), which is often interchangeably referred to as “cloud computing”. While pundits may disagree on whether SaaS is cloud computing, its primary feature is application provided as a service to customers via the internet.  Because applications are hosted, this eliminates the need for installation and running of applications on clients’ computers, or even servers, as well as maintenance and support. Moreover, SaaS reduces the need to purchase and maintain hardware.

But before getting into the much-praised or marketed trend, it is worth considering first why SaaS is such a hot commodity nowadays.  According to experts, security, maintenance, and cost are among the top reasons why SaaS is being embraced by enterprises.

Moreover, due to the challenges that face companies regarding outsourcing, such as communication gaps and security, SaaS either supplements the need of businesses to outsource parts of their IT requirements. This is especially helpful for small and medium-size businesses that do not have large IT departments, or those that can only afford to pay general IT workers instead of specialists. Because staffing has become problematic due to reduced budgets that affect tech spending, SaaS offers a way to meet their technology requirements without spending more on overhead.

Whereas the application service provider (ASP) business did not make as much mark as it should have in providing enterprise computing, SaaS is being touted as the trend that will replace and even overcome ASP.  Scaling was ASP’s main challenge, which required “separate execution environment” or different server environments for hosting different applications.  SaaS replaces multiple resources to run applications with shared computing resources, such as the same software version that runs on the same platform. This proves cheaper for end-clients.

SaaS providers offer flexible contracts that have targeted costs for specific services. Many tech projects run for only a few months, so services that provide exactly what businesses need in terms of scope and time, with corresponding costs, are advantages that SaaS vendors are only too happy to explore.

SaaS provide specialized software that increasingly meet clients’ needs. As vendors gain more knowledge about what businesses want, these insights are incorporated into version upgrades, which means better software and, just as important, more responsive service.

It is common knowledge in any industry that freeing up the need to manage back-office processes, including technology services, allows companies to concentrate on bigger, more important business areas. Perhaps at the IT level itself, this is also true. Freeing up the upkeep of some technology processes allows IT departments to focus on the services that they can provide in-house.  In effect, SaaS vendors upgrade the quality of both hosted applications and, indirectly, the quality of services of in-house IT departments.

By ExecutiveBrief
www.executivebrief.com

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

Last night I attended a party at an old friend’s house.  After small-talking my way around the deck, I hooked up with some old acquaintances, with whom I had participated in a software project.  The gig we shared had taken place back in 1999, in Atlanta.  It was one of those 90’s love-fest dot-com jobs.

While sipping cokes and gobbling slices of homemade pie, we discussed the project’s failings.  “What went wrong?” I asked my colleagues.

“I think it was the fault of the CEO,” one said.  “He just had no experience, and wasted all the money.”

“No, the development organization was all messed up,” the second said.  “The lead engineer kept jumping in and changing everything I did.”

“Well, I think they spent all their money on marketing before they even had a product to sell,” I put in.  “You have to make some sales and get customer feedback before you can spend millions on marketing.  Don’t you think?”

The discussion heated up for the better part of an hour, and I realized that none of us, even ten years later, knew exactly where the faults were.  Who had messed up?  What had gone wrong?  Why hadn’t we succeeded in shipping a product and engaged the sales channel.  None of us knew for certain, yet we all saw some pretty gross mistakes.

That really got me thinking…  Sometimes project failures are not as easy to diagnose as one might think.  Even by salty old dogs like us.  And everybody has their own opinions.  Think about that the next time your project bites the dust.  Or before it does.

–ray

I once read a bizarre statement, written by an overloaded IT manager.  He was complaining about the heavy workload his executive management was throwing on him.  Here is what he said:

When a new project request comes down, I just ignore it.  I ignore it until management makes it clear my job depends upon it.

Wow!  That’s revealing!  Evidently, this poor soul is so swamped with exciting new projects that he is forced to ignore the bulk of them.  I can vividly see how these superfluous demands go down.

First, the executives get a great idea.  Yeah!  Let’s restructure the customer database to maximize the communication [read: spam] we send out.  We’ll get some great sales!

The project is handed off to Harold in IT.  “He’ll make it happen,” the suits say.

Harold comes in Monday morning, sorts through 400 spams, and finds the outlandish request.  He rolls his eyes and drops it into the “Oh Boy!” folder.  And then he checks the ESPN stats.

The execs never give the project another thought.  They just go off and reinvent the company ten more times, dumping an equal number of requests on poor Harold.  And he ignores them all.  He doesn’t have time for the fun.  He’s got real work to do.

Am I off?  Got it all wrong?  Honestly, I don’t think so.  I’ve seen numerous projects like this get swept under the rug.  Execs don’t run the show, the little guy does…

–ray

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

�

I suppose it goes without saying, but with a down-economy, now’s the time to bill clients for every hour you’re entitled to.  And to watch your resource utilization more closely.  Below are some areas to watch for.  Consider a product like Standard Time® to make them happen.

Resource Utilization
Resource utilization is the percentage of billable hours your employees are working.  Let’s say there are 172 billable hours in a give month (every month is different).  And let’s say Fred only worked 45 of them, and Angie worked 100.  The utilization rates would be 26% and 58%.  Not great, but workable.  Can you make money at those rates?  Well, that depends upon employee salaries and overhead.  Increase your utilization rates, and you win.  The image below is a report of utilization rates.

Utilization Rates

Correct Billing Rates
For every hour you bill clients, you have a billable rate.  Those rates depend upon employee skillsets, and the tasks performed.  Research and Development will naturally bill out at higher rates than travel and meetings.  I recommend using Standard Time® to monitor those rates for each employee.  Make sure you’re billing at the correct rates, and for every hour your people are employed.

Communications and client Login
Clients like to see what you’ve been up to.  Without a client login into your time keeping software, they aren’t certain what’s being done on their projects.  They begin to wonder.  Give them a client password, and let them peek into their own projects.  It will aid in your communications efforts.  Communications is everything in client relations.

The folks at Standard Time can demonstrate all these areas:  Give them a ping!

–ray

It is not enough to manage projects virtually, but to properly apply e-project management processes that result in less development time but with improved quality. This is about value and not just cutting costs, after all.

Advancements in telecommunication are among the key movers of offshore outsourcing. Without it, back-office operations and application development outsourcing will not be as successful as they are today.  Better infrastructure has allowed for richer applications and cheaper communication that enable businesses and their outsourcing partners to manage people and projects efficiently from different time zones.

Adopting virtualization in managing project offers great competitive advantage to companies and offshore project teams. However, with the increasingly virtualized tech industry, it is not enough to manage projects virtually, but to properly apply e-project management processes that result in less development time but with improved quality. Remember that this is about value and not just cutting costs, after all.

To make a successful adoption of virtualization, a few key elements are involved.

Infrastructure – Both client and vendor must set up the infrastructure that can support virtualization efforts, particularly when the project at hand involves sensitive information.  Both parties need the hardware and software to host VoIP calls, and in many cases, virtual private networks (VPN).  At the start of the project, prioritize the acquisition of hardware, software, and bandwidth to support collaborative and communication efforts.

Communication Plans – Much of the success of adopting virtualization in depends heavily on communication.  On-shore project members do not have the advantages of following up colleagues whenever they want or in person. Delivery teams, on the other hand, do not have the luxury of clarifying project details immediately. In this regard, it is best to set up communication plans that define identify proper channels and approaches. Are there available people on the other end of the communication line? When should the team use virtual meetings? Is e-mail enough to update one another about the project status? Who will project members ask about issues—specific persons or entire teams? Experts agree that it is better to err on the side of over-communication.

Control and Evaluation – On top of delivering results at a time when they are expected to, offshore project teams should report plans for manpower allocations and utilization, risks and issues, and milestones.  By having these details, project teams—no matter where they are in the world—can evaluate project status and control risks. This also involves a single control system that allows for an easy generation and consolidation of data.  At the end of every period—typically weekly or monthly—such data can be measured to evaluate the success of the project in terms of quality of work, manpower and financial investment, and the lessons learned from the venture.

Collaboration Tools – A repository accessible to every member of the delivery team should be put in place. Do not rely merely on multiple copies of outputs stored in individual folders. Versioning and project management software, such as SharePoint or Perforce, allow project team members to work on single source copies of outputs, as well as archiving, checking out and backtracking of works.

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

It is easy to become victims of the media’s scare tactics and dramatization. It is no longer good enough to simply report facts. The 24/7 news cycle has many news organizations using entertainment to fill air time. It is common knowledge that shock sells. So, we are now inundated with doom and gloom from the ever-present talking heads. Somewhere in between is the truth.

This brings me to a point about projects and the slowing economy. Should we all just stand still and wait to see what happens? Or, like many companies, do we look at this as an opportunity to gain more market share?

Projects evolve for many reasons, but even more common among them, is the understanding that projects will either create a revenue stream, or they will streamline costs which will in-turn add to the bottom line. Yet, for many businesses fear takes hold and many stand pat. If a project will save you money or make money, why stand still?

During the dot-com bust and the days following September 11th similar economic fear gripped our nation. I remember working for a small company that decided to go bold or go home. If the business was going to fail it would do so despite vision and forward thinking. The company grew and was more profitable, while a few of our competitors fell, in part, because they froze.

I believe in being prudent, but I do not believe in giving into fear. If a project makes sense, go for it.  If not, make sure it is not because of fear.

 –Warren

It is not easy being perfect, just ask Ed Hochuli, a widely respected NFL referee who blew a huge call last week during the Denver Broncos’ San Diego Chargers football game. You can not miss this guy. He has been a referee for many years and has worked playoffs and Super-bowls. Not to mention his arms are the size of tree trunks and he looks like he should be playing line-backer instead of throwing flags.

Anyhow, the point I am trying to make is that this guy set the standard for NFL ref’s throughout the league. Week after week, game after game, Ed Hochuli was the definition of steady and consistent.  In the world of referees, he was considered the best. Then came last Sunday, one bad call and bam!  Many in the media and fans across the country deriding him as brainless and calling him the worst referee on the planet. 

However, Ed is taking it like a champ. He is facing up to his giants. After receiving hundreds of hate filled e-mails, Ed is personally responding to every single one with a sincere apology.

So, what is the lesson in Project Management? You have got to be on your game and make the right decisions without EVER making a mistake? That’s impossible! But, what we can control is how we respond. People respect someone who takes responsibility for their mistakes. So, own up to it and move on. Only then can your team do the same. 

–Warren

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

I have written in past blogs about Project Management being a lot like coaching. One part of this I want to elaborate on is our words. I can imagine, in the heat of battle, coach Paul “Bear” Bryant would drop a few “f” bombs on a player, get in his face, and challenge him to do more–and to do it better.  That does not fly as well in the corporate world. A football player can rush on the field and translate that aggression into physical action. It works on the field but not so much in a cubicle.

However, in the office, a manager must still learn to pull the right strings and push the right buttons. The best way to do this is by getting to know your team. Use personality profiles, spend time with your employees sharing their interests, and things outside of work. Then, you will have a better feel for who needs a kick in the pants and who needs a pat on the back. NOW GET YOUR TAIL OUT THERE AND MAKE SOMETHING HAPPEN…and do not drop the ball. 

–Warren

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

Call me crazy, but it seems that when summer rolls around work and projects slow down.  So, I say, do nothing. Well, that does not go well with the boss so what is the alternative? There are key people on vacation every other week. Then others are taking off early on Friday to make a three day weekend. Before you know it key decision makers are consistantly out of the loop and major milestones are delayed. So, you dump more work on the “active” members of the project and it slows their work down, or seriously inhibits their quality of work. Either way, it is not pretty. Most managers will tell you to build in a cushion for these types of issues and delays. I say take the summer off.  How about you, any suggestions?

-Warren

Hello,

I’m a project manager for Hewlett-Packard and enjoy my profession.  A power nap doesn’t apply to all, as there’s some people who can’t get to sleep for awhile … maybe to tense or tight … then there are some of us … who work from home … didn’t sleep so well the night prior and sometime during the day are tapped … so I recommend - “The Power Nap” … which for me these days is about 10 - 15 minutes and then I’m good for another 2 hours at least … one can set the alarm on your cell phone {make sure it’s on the standard setting, not vibrate} and enjoy … I find I’m totally refreshed and can really be productive on the next challenge, as opposed to trying to push my way through and aren’t as effective as a moment will provide … and for those working in an office … I guess there’s always the jaunt out to the car for that quiet moment …

I used to drink coffee to muscle through those moments but 15 - 20 cups a day makes me jittery by the end of the day. 

Hope this helps and … may your journey as a PM be an enjoyable one.

God bless.

Cheers,

Bill

Are your projects DCAA (Defence Contract Audit Agency) compliant? Maybe you have never heard of this term or perhaps you have never worked with a government contract. In any case, for many people it is highly likely that some day you will. 

Becoming DCAA compliant can be a daunting task. It requires some very general rules on some items and is very specific in most areas. There are guidelines on how to submit proposals, how to track work on those proposals, and it even mandates internal procedures to comply with the DCAA’s rules and regulations. It is so steeped in red tape that there are nearly 100 classes offered on DCAA compliance training. I would not dare bore you with all of the details here, but it is worth noting that consultants/accountants are available who specialize in this field. However, be warned, they are not cheap. 

In addition, there are time keeping/project management tools available like Standard Time that support project efforts to become DCAA compliant. There is a sizable market in government contracting and a nice cottage industry for consultants that specialize in government contracts.  The moral of this blog is take advantage of the expertise available to avoid having to sit through 70-80 classes on DCAA compliance.

–Warren

Resource allocation in Standard Time®is very straightforward, mostly because ST does not have the complex scheduling capabilities of Microsoft Project.  The image below shows a (compressed) screenshot of the resource allocation window.  We’ll discuss how to display and manage task allocations.

Standard Time Resource Allocation Window

 First, you should realize that the bars represent hours worked in a time period.  The resource allocation window collects all tasks assigned to each employee, and assembles them into time periods based on their starting dates.  If you have ten tasks that all add up to 80 hours, you might see two bars, one for each week.

The red bar in the image above represents a over-allocated week.  That means you have too many tasks to be performed in a single week.  Yellow bars indicate to little work (or under-allocation).  Blue bars are just about right.

Simply create new project tasks and give each one a starting (and optional due date).  When these tasks are assigned to employees, the resource allocation window shows them split up into time periods.  That’s about all you need to do!  It’s pretty simple.

–ray

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

 Effort driven scheduling: Calculating project task duration based on assigned resources.

When you assign resources to a project task in Microsoft Project, it recomputes the ‘Duration’ field.  The screenshots below illustrate this.  We’ll begin with plain tasks with no resource assignments.  After creating the tasks, we’ll assign the first resource, and then all the rest.  We’ll show that the ‘Duration’ column is changed when more resources are assigned.

Tasks with no resources assigned

Why does Microsoft Project recalculate the ‘Duration’ field when new resources are assigned?  The ‘Duration’ column indicates the calendar time that will elapse as the task is being completed.  That may be different than the ‘Work’.  If more resources are added, the calendar duration will go down.  That is effort-driven scheduling - based on employee effort.

One resource assigned

A magical thing happens when we assign multiple resources to tasks.  Notice that the ‘Duration’ column is reduced to reflect the extra effort applied to the tasks.  Since the tasks are effort-driven, they require less calendar time to complete.

Effort-driven task scheduling

–ray

Many banks offer overdraft protection for their customer’s checking accounts. It could be for an attached savings account, a small line of credit, or another mechanism designed to cover any over-runs on your checking account. After all, mistakes happen. This is a little insurance policy you may never use, but it is better than paying large overdraft fees.

So, why on earth are we talking about this in a project management blog?

Well, it is simple. Do you have any protection against project budget over-runs?  Any last line of defense?

A main part of a Project Managers’ job is to successfully finish a project on time and under budget. With all of the variables involved, that is a tough proposition! For help with cost over-runs you may consider a tool like Standard Time®. Standard Time contains an automated feature that sends warning e-mails when a task or project is nearing the intended limit. In addition to the warnings, a Project Manager can set a “no pass” limit that will prevent an overrun or an allowance, but only if the Project Manager/Administrator allows it.

Task Warnings in Standard Time®

Nothing is fail safe. However, Standard Time is one tool that identifies impending problems and may be the extra nuance that keeps your projects on track.

–Warren

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

Yo, dog…  Where my ladies at?  Got me a grip a cash an’ a HP blade.  I’m a IT professional!  But where my womens at, yo?

I’ve decided to convert this blog to attract the hip hop community.  Especially those from the IT industry.  How am I doing so far?  No, really, I’m just wondering where the fine ladies are at in the IT industry.  Coders, network admins, dbo’s, project managers.  There’s only one for every four men.  That’s right, about 25%.  Check out the links below.

http://www.cioinsight.com/c/a/Past-News/Numbers-Show-Big-Decline-of-Women-in-IT/

http://news.zdnet.co.uk/itmanagement/0,1000000308,39352947,00.htm

I have my own theories about the disparity in numbers…  To me, the ideal IT employee nests in the server room amongst the network cables, routers, and modems.  He beds down with a blade under his pillow - an HP server blade that is.  Occasionally - usually on a full moon - he emerges to shower, change his crusty socks and underwear, and prowl for chicks at the all-night gaming bar.  He writes a staggering mountain of code, making dark hackers look like kiddie scripters.  In past lives, I was that foul-smelling geek - so I know.

Now,,,,,,,,,,,,,,,

Show me a girl who wants to live like that.  Sure, I’ve seen lots of nice professional women in the IT industry.  They wear nice professional suits, and make their hair up in nice professional styles.  They’re nice.  Professional.  But they don’t “live” for the bits.  In my 25+ years in the biz, I’ve never seen a true geek chick - one who codes until her eyes run and sleeps under her monitor.  (Yes, I’ve actually bunked under my computer desk, and so have some of my friends.)

Once an IT department gets a few guys like that, they don’t the respect the “nice professional” types.  I’m sorry for the crude characterization (and maybe I’m dead wrong), but passion for the bits still sells, not professionalism.

Peace Out,
–newshirt

There has been a lot written in the past few years about outsourcing technical support and SaaS (software as a service). It is not an easy choice for a company to make. On one hand, dumping all of your IT issues on someone else may save a few dollars and headaches.  On the other hand, you do not always have control over the type of support your company receives–costing you more in the long run.

While many companies are using SaaS, many other companies do not. It is easy to get caught up in the latest trends, but trends are just that, and they are not always permanent. I have had the priviledge to work with a lot of major U.S. companies and while I can not say whether outsourcing is a true fad or not, I can tell you, imperically, that 75% of my contacts keep everything in-house. So do not be swayed by all of the tech media and exposure of recent trends. There is a place for both internal and external IT support. I guess it all comes down to cash flow: which one can I afford right now, and which one will be better in the long run?

–Warren

CIO Insight had a short article that got my attention.  See the link below.  It caught my attention because it lists the business areas where CIO’s are not typically involved.

http://www.cioinsight.com/c/a/Foreward/What-IT-Leaders-Dont-Do/

Areas CIO’s are not involved: 

1. Choose geographical markets to enter
2. Choose product markets to enter
3. Choose product lines to enter
4. Hiring non-IT employees
5. Acquiring other companies
6. Merging with other companies

I’d like to hear your opinion!  Should CIO’s be involved in these areas?  The first three are the domain of sales and marketing executives, and the last three belong to the CEO (who the CIO normally reports to).  So what involvement should the CIO have in these areas?  I would think little, if any.

CIO’s typically care about the information infrastructure of their organizations.  So how do these things apply to that.  Well, there’s web sites, databases, web services, network traffic, logins, etc, etc, etc.  I suppose that’s a fair degree of overlap.  But does it warrant anything more than a token seat at the conference table (when discussing the issues)?

Your thoughts?

–ray

Every project manager knows he must identify project risks, document them, and resolve each one.  In other words, he must learn what could jeapardize the duration, budget, or quality of his project.  If you don’t, the project may fly off the tracks and you’ll look bad, or worse.

Problem is, your engineers are hiding those risks from you.  The fictional dialogue below shows how it happens.  It is a faux conversation between your project manager and one of the engineers on the team.

PM: “I love your new designs!  This project is really coming along.”
Eng: “Uh-huh.” (hoping to be left alone.)
PM: “Do you think you’ll be finished by October.  Big deadline you know!”
Eng: “Of course.” (barely lifting his head.)
PM: “Any risks or unknowns?  How about that integration task?”
Eng: “Nothing I can’t handle.” (peering deeply into the montor.)

Engineer-boy has two problems.  First, he’s a little too independant to admit he needs help.  Secondly, he won’t risk the tarnish to his stellar reputation.  No white-shirt, tie-bearing, non-pierced PM will ever get him to crack.  He’ll work all-nighters if he has to, or so he tells himself.

–newshirt

I have been in sales and marketing for some time now and I work with Project Managers (PM’s) nearly everyday. It struck me the other day how similar PM’s and sales forces really are. Project Managers are sales people on many levels. Project Managers often have to sell the benefit of an idea to get their teams motivated. Project Managers identify problem areas to avoid, as do sales professionals.

An interesting twist on this is taking the problem a step further and identifying the problems’ implications and consequenses in any given project.  It is one thing to note a specific problem, but if you really want to wake the team up, talk about the implications of that problem in greater detail. Bring up examples of likely scenarios and issues that could arise. By stressing the implications, you will put a magnifying glass on the issue and focus on the ways to avoid that pothole! After all, problems come and go, but the consequences may not.

–Warren