When someone asks my opinion on their writing, I'll get fairly detailed; I've noted in the past that there is a lot of power and influence in the written word, and it's fairly important to get it done well, or your project proposals just never seem to get off the ground. This particular proposal suffered from a lack of direction; it didn't take the reader (the decision maker) through a clear progression. Admittedly, the subject matter was a bit technical and…
Spent time at an industry conference last week (ain't Boston great!), and heard the term SAPanese - that special language SAP users learn when immersed in worlds of Walldorf and their ubiquitous software. It's not unique to SAP - lots of software companies develop their own vocabulary. Heck, IT "geeks" are famous for it - even the various functional units within the business develop their own shorthand, terms to help speed communication with "those in the know". Here are some…
In a recent post on Thinking Faster, Phillips expresses concern about the apparent propensity for project sponsors to skim over the details and jump to quick answers. He's talking about [what I believe is] a peer relationship, when external expertise is brought in to develop the solution that they (the sponsors) are responsible for "owning" (vision, design, execution, and ongoing support). I've seen the same sort of thing in multiple organizations, especially when talking with executives about projects and initiatives…
An excellent discussion this afternoon, on a fairly complex topic we're trying to move forward. When dealing with broad system concepts that have been trivialized into TLAs - think CRM, PLM, BPM, TQM, yada - you need to help folks define some sort of framework to focus and steer the initiative in a general (hopefully correct) direction. Precision is not required in the early stages - like herding cats, we can start making progress when we can capture a generalized,…
I use a number of euphemisms all the time, in my conversations with folks, trying to balance complete yet brief communications. A common phrase when trying to show that you've seen a similar situation before is ... "In a previous life ..." (IAPL), as in "In a previous life, we did consolidated financials within the ERP ...". I find it's a bit smoother than citing the bigger company you used to work for (sounds condescending) or the smaller company you…
We've faced this problem a few times, as we roll out a distributed application across a network of remote locations. A fairly typical challenge is to explain the impact of a technical architecture improvement in a relevant, meaningful way - without resorting to techno-jargon. A good approach includes: Keep it short - Too much detail and you will lose them. Find the balance between enough information to be valuable, but not so much as to be boring Focus on the…