fighting the lack of good ideas

pxe works differently in hpsa 10.x

2 years ago I wrote-up how you can change the default choice for the PXE menu in HP Server Automation. Found out this week that those instructions are not valid if you are running 10.0 (release this past summer).

HP changed how they present their PXE menu with 10.x, and I have filed an RFE (on 18 Dec 2013) with them to get this fixed back to how it was (or provide a solid alternative).

This is one of the times when I’ve ever seen a vendor remove functionality in a product (at least, removed without providing an alternative).

Thanks, HP 😐

what should a professional services group’s goal(s) be?

Should it be as a revenue stream? Or can it be far, far more?

Every place I have worked since getting into professional services back in early 2008 has viewed the goal of the organization as making money by performing services. Whether or not the customer was happy, something useful was delivered, whether a relationship was engendered and cultivated, and whether there were any future opportunities to do work with the given customer were at best secondary, and often viewed as completely unimportant.

I recently spoke with a company about their nascent proserve wing, and heard a view I’ve had niggling at the edges of my thoughts about how the previously-described environments fail, but couldn’t quite word myself. They view their work as enabling the customer. Proserve engineers spend as much time on this team delivering educational resources and engaging disparate teams from customers as they do actually “working”.

This company, which shall remain nameless for now, doesn’t worry about billable hours for their consultants – they worry about making sure that their customers are benefiting from the product they have purchased. Services aren’t free, but they don’t exist to “make money” – they exist to support, extend, and empower customers to use the product better in their environment. Positive side effects of this approach include bringing new techniques and applications back to the team from various places, and a low-pressure feel (though in a highly-involved and solidly-booked team) to every engagement, as much as possible.

Because the company’s goal is to assist their customers, product engineering, support, proserve, and sales are all working together as a team to get stuff done. Everyone is contributing because it’s vital to get customers happy. They’re already using some of the concepts I outlined in my advice on creating a successful support organization, but are taking them further by applying those ideas and approaches across internal structural divides to make the whole company as effective as it can be.

The organizational mindset that believes everyone is onboard to make customer experiences as good as they can be is one that needs to be adopted by every company across every team.


I am a huge believer in unsales. And not in the pharmaceutical industry sense.

Because “shipping is a feature“, and because I intensely dislike the “do it for me, then hand me the keys” mentality, I routinely follow the unsales methodology.

What is unsales? It is [almost] only selling what a customer can use today. I want to give a customer something they can both use and play with. I want to give them something at the end of any engagement that does actually accomplish something. But I don’t want to do everything for them – I want them to learn, explore, and discover their own use cases. As they discover what can be done with the tools they’ve purchased, they can start to engage in the paradigmatic shift from “automating” to “automation“. And as they explore, discover, and build, they’ll start to see where further services, training, or products can be brought in to do more.

Some people believe in the “moneyball” approach – sell everything (especially the big-ticket, high-margin products), and then let the customer more-or-less fend for themselves after some extended period of services work.

This is good for the vendor doing the selling … but only this quarter. If you sell “everything”, you have no basis to come back to the customer. You’ve developed no relationship. You’ve only “made a sale”. You’ve followed the Walmart model – sell what you can, when you can.

The better model, in my opinion, is the relational model wherein you spend time getting to know the customer’s employees: the engineers, managers, officers, etc. Get to know them personally, and become someone they can turn to as a “trusted advisor” regarding their pain points.

Relational selling (and working, for that matter) tend to lead towards long-term partnerships, engagements, repeat business, etc.

You can take the short-term view, or you can take the long-term view. One yields consistent returns, one may only ever give a single return.

Be relational.

there’s never enough documentation | there’s too much documentation

Documentation is vital. There’s never enough. And there’s always too much. In general, these are the areas I find documentation to fail:

Not Enough Too Much/Many
why-tos (instead of how-tos)

tutorials on things you need

architecture explanation

design philosophy “how we got here”

“why we are here”

future plans / roadmaps

deltas from standards recording

back-/cross-references to extant (even from other vendors / sources) documentation

extraneous verbiage – use terse verbosity

tutorials on things you don’t need / care about

discussion of non-core aspects of the product

how we used to do things

assumption of comprehension

plagiarism – ie, non-attribution of sources

braggadocio (not just excited) tone

different “voices” or styles

I have no quick-fixes. But I hope the above can help to address problems and help those responsible for documenting what they do to make it better. In the tech world, MSDN and developerWorks are the golden standards by which all other documentation should be compared … and to which [almost] all other documentation fails to aspire to.

the value of face-to-face

I have been working from home for nearly 5.5 years.

The benefits are myriad – not least of which is the minuscule commute and savings on fuel, eating out, etc.

Sometimes I travel for work. This accomplishes many good things – a chance to put faces to names and voices, get a chance to read faces and body language instead of just vocal tones, engage more of a customer’s engineering staff, etc.

Remote meetings (Skype, Lync, Google Hangouts, Webex, GoToMeeting, etc etc) are fantastic tools. Being able to work via VPN or other tools is amazing.

But nothing can replace the face-to-face meeting. Video calls are good, but not a full replacement. As more and more employers embrace optional and/or suggested remote work arrangements, workers can be more and more productive – with less downtime and wasted time (eg commuting).

But never let the power of remote engagement become a full replacement for the power of personal connection when in-person.

new documentation should always augment the status quo

In my line of work, I often need to create documentation for clients.

Documentation in general is a Good Thing™.

But good documentation’s goal should always be to augment and improve upon what already exists – not to supplant, downgrade, or muddle what already exists.

A prime example of this has come up with a client partner recently. They asked for “as built” documentation. They failed to define that term. It turns out that their definition of “as built” is a “screenshot-by-screenshot” replacement of the vendor-supplied installation and configuration manuals.

This is a phenomenal waste of time, effort, and space. “As built” should mean to note any deltas or site-specific configurations that vary from or augment the vendor-supplied manuals.

Why is this the case? Because recreating vendor documentation means attempting to do a better job of documenting a product then the people who wrote it! The odds of you being able to do this are extremely low.

In fact, I’d go so far as to say you cannot do it. Ever. The vendor has dozens, scores, hundreds, or even thousands of man-years of experience with the product across the whole team. They know where the source code sits, and can reference it directly. They have the ability to truly say what is and what is not authoritative on the product.

You will never be able to outdo them. Even if you have been using the product since it was in pre-alpha form, you cannot, as one person (or even an outside team of people), possibly have as much experience as the development and documentation teams that design, build, and describe the toolset. They don’t just hold the trump car, they are the trump card when it comes to how something works.

Whenever you document a process, make sure that you document anything that is site-specific about what you did. Make sure you reference the vendor’s materials as often as feasible to make sure you backup your claims and directions with authoritative data.

But don’t worry about recreating what the vendor has already done – your documentation, in this regard, will never be as good as the vendor’s: they publish errata notices, updates, etc. You have to do the same to have a remote chance of matching them.

You will not be successful.

Focus instead on making great documentation that goes hand-in-hand with vendor materials to supplement them; don’t try to supplant them.

pmp project management professional certification exam preparation course in a book for passing the pmp project management professional exam by william manning

New record for longest blog title I’ve ever had. I think.

First, the pros: it’s concise, finishing at a mere 91 numbered pages, including sample questions and the index.

Second, the cons: it’s 63 pages of bullet points with little-to-no explanation of terms, examples, etc.

William Manning appears to have done an admirable job of summing the salient terms and processes from the PMBOK in this absurdly-long-titled bookette.

I picked this book up recently to give an overview of the PMP exam, as I’ve been considering something of a career shift/growth move into project/product management from technical architecture and delivery. I now know that I know the vast majority of what is required for the exam, but not necessarily with the official terminology. That means I need to learn definitions and applications of terms.

I also need a “real” prep guide – one of those tomes that weighs-in closer to 500 or 800 pages, and not the mini guidette Manning has provided.

Is this a good book to get as a last-minute review of the PMP exam? I think so. Is it worth getting if you’ve never seen/done any form of PM-related work before? Absolutely not.

PMP Project Management Professional Exam Preparation Course in a Book for Passing the PMP Project Management Professional Exam. Now there’s a title.