PoddarCo

Processes should exist as a catalyst for getting work done, not to slow it down. Checks and balances are needed to ensure nothing slips through the cracks, not to cover one team’s tracks so the next in line can be blamed. Documentation is prepared to pave the way for others who follow, not to constrain projects till every excruciating detail is noted.  Dates are necessary for planning, scheduling resources and aligning other work, but need to be kept real.

Some PMs get caught up in demanding these elements from their teams and resources. Releases don’t get scheduled till project codes, install instructions, help guides, dev complete dates, QA completion notices, team-to-team hand off meetings, multi-layered sign-offs and varied support procedures among other things are in place. By then the business (client) needs move on, project demands change, resources shift.

It’s here that a customer focus plays a crucial role.  A customer focus can shed new light on questions like – how can the process minimize redundancy and overhead while maximizing productivity and utilization? Does the process have to be so standardized? Where can you make the process flexible?

My two cents in conclusion: question the rigidity of processes and other must-haves; be alert to these things when they start becoming roadblocks.

(On the homepage, click speech bubble next to the title to leave comments. On the post page, scroll down.)

Occasionally even in your spotless careers, you will come across clients or stakeholders who may be upset with you or your company.  Let me share a personal example.

Early in my career a crucial client meeting was cancelled after a brief discussion between the executives at my company and the executives at a client’s company. However, none of the invitees were notified. This was going to be my first meeting with the client (some introduction, right?). There were at least five vice presidents flying in from out of town just to attend the meeting. Guess what happened on the day of the meeting? They all arrived at the meeting location only to find out an hour before the meeting that it had been cancelled.

No one from either company owned up for the miscommunication. But these people were upset. I let the first few hours pass expecting the executives who had caused the miscommunication to sort it out. But no such thing happened. So the first thing I did next morning was pick up the phone and call every single invitee and apologize for the miscommunication. I took the hit then, on my first call with the client. But it was the best thing I did. It established a relationship. The client turned into one of my most successful ventures and a couple vice presidents became life-long friends.

Sometimes the easiest things are the toughest to do. Talking or meeting face-to-face can work miracles. Just do it.

(On the homepage, click speech bubble next to the title to leave comments. On the post page, scroll down)

Are you afraid of a client’s skepticism towards you when you first approach them? Do you get butterflies in your stomach wondering what would be a good way to start a dialogue? This white paper explores some basic steps you can take during your first meeting or phone call that will help you create a successful first impression — which will in turn lead to a healthy relationship.

For more details, please click the White Papers link on the top right corner of the screen. If you are a PMI member, you can also find the white paper under Virtual Library Resources – People Management.

Title: Hushing Butterflies When Making the Dreaded First Impression

Weighing the pros and cons of applying a combination of techniques from Waterfall, PMBOK, Lean, Agile or other methods is outside the scope of a blog post.  However, in researching the benefits of marrying some techniques from various methodologies, IMO it’s worth taking a para out of agile when it comes to handling customization.

By focusing on iterative releases, agile methods create room for changes to be incorporated into the development process.  They maintain good visibility of features implemented and backlogged.  By using a collaborative team and involving customers in product demos before the end of an iteration, agile practitioners ensure customers drive the end deliverable.  Viewing agile through this lens for now, what can you incorporate into your project management technique to handle customization better?

When new requests put the scope at risk, customers are often told to wait till the next requirements cycle or the end of the project.  IMO don’t make customers wait – capture all requests as wish list items at the time of request.  Categorize requirements as must-haves and nice-to-haves.   As soon as feasible, establish a release plan – a second round of development – during which these requests can be addressed (in release 1.5 after release 1.0 or a quick-fix after the release).

As you transition from phase to phase, establish go/no-go checkpoints.  At these checkpoints involve customers or stakeholders – show product demos, get feedback.  You will be surprised how some of the quick wins can reap rich rewards without much deviation from the baseline.  Besides, your customers will be happier that you listened to them even if you can’t deliver everything right away.

I don’t think there’s a one-size fits all solution.  What works for you may not work for a project manager in another industry or environment.  Nonetheless, there’s more in common than meets the eye, and takeaways from one approach will benefit the other, and the project manager’s skills.

Tomorrow – Handling Customization: Bagging the Quick Wins – CSF vs. LOE grid

Click here to leave a comment (or click the speech bubble next to the title)

Since my last Friday flare-up was on handling customization, this week I’ll explore some basic actionable steps to build into your processes (to handle customization successfully, duh!).

How does one address customer requests in a structured manner?  Establish bi-weekly calls with your customers.  During the calls inform them about new developments at your company.  Ask them about their needs.  Document their requests as wish list items so these requests are traceable.  Assess which requirements are in greater demand – maybe multiple customers are asking for them.  

Take these items to your organization’s professional services or development teams, or steering committees.  Push for them to be incorporated into your product or service.  In follow up meetings, proactively give your customers a status update.  Give them an approximate idea of the timeframe and costs.  Do not hesitate to quote a price.  There will always be room to negotiate.  Prior research into the customer’s budget, functionality’s market appeal and cost will help negotiate better.

Tomorrow – Handling Customization: Steering Committees

Click here to leave a comment (or click the speech bubble next to the title)

You feel your customers keep changing their requests or making “seemingly” unrealistic demands for customizing your product.  So what?  Don’t balk at them!  It pays dividends to keep an existing customer happy.  It pays greater dividends to not lose a customer!  After all, if and when things do come down to that, you may have to give in to all the customization and perhaps more.  And who knows, maybe even for free.  I am not saying you bend backwards from the get-go, but there’s a manner in which to approach any customization request.

Changes will happen.  Customers will look for new functionality and customization in your product so they can adhere to their processes and execute per their strategy (which isn’t static either, esp. in this business environment).  Instead of worrying how the customization impacts your product roadmap, spend your energy researching the requirements first.  Reach out to other existing or potential customers to assess what the functionality’s broader application is.  Then, appropriately plan for it in an iterative release or future product, and perhaps even charge extra $$$ for it.

Many times a product gets enhanced not because the genius in R&D had a brainwave (no offense to my R&D friends) but because you listened to your customers.  This may not apply to Microsoft and Yahoo, but at least the small to mid sized software companies out there, listen to your customers. Comcast – know that you never listened to me and I am waiting anxiously for the day I replace your service!  Fios – where are you?

Click here to leave a comment (or click the speech bubble next to the title)