‘Asset Bubbles’, The Speed of Electrons, and Your Money

What’s an ‘asset bubble’?  We’ll see in a minute, but first, some background…

Ever made a payment online?  Of course you have.

I now pay my credit card bill online.  I don’t do an automatic payment – I like some measure of “hands on” control.  But I know this:  Once I execute a payment to my card company, by clicking ‘Submit,’ I receive a confirming text message to my phone nearly instantaneously.  I’m talking about a couple seconds.

I pay my car insurance online.  When I execute payment, I get an e-mail confirmation almost immediately.  Within a minute, easily.

Same for cable.  Same for power.  These transfers (both in terms of money, and communications) happen with a speed of execution that is extremely efficient.

Not so for certain other transactions.  When I initiate a transfer to my bank from PayPal, I’m advised that the funds will be in my bank account between 3 and 5 days’ time.  Meantime, my PayPal balance is 0 (or down by whatever amount I’m transferring).  So, where’s the money in the meantime?  And why can the transfer not be immediate, as in the former cases above?

When I do a bank-to-bank transfer, I receive a similar counsel:  The money will be in my other account in approximately 3 days.  Meanwhile, the originating account is debited – but there is no credit (yet) on the other end of the pipe.  Where’s the money?

Well… it’s obviously in some kind of limbo.  That money does exist:  It’s not vaporized while “in transit.”  However, wherever it resides, you can bet it is making money in the form of interest, or lending itself to investment.  How?

Just consider the one case – that of PayPal:  They are transacting money all over the world.  PayPal is handling money in the millions, likely billions, of dollars.  At any given moment in time, PayPal has a tremendous amount of money in limbo, suspended between various accounts during those 3-to-5 day delays.  This represents an ‘asset bubble’ and that pool of money on a balance sheet is a resource:  That resource of money is earning interest, or funding investments – at least, it seems to me.  Meantime, you wait for your money to transfer at the speed of… well, something other than electrons.

This would seem to be a newsworthy story, and a ripe area for a little legislation.  A 3-to-5 day delay is not necessary in vetting the transfer of money.

What do you think?

SMB: When Do You Need a Mobile App?

More and more businesses are implementing and leveraging mobile computing for optimal competitiveness.  No longer are mobile solutions the sole province of large companies; small-to-medium businesses (SMB) are jumping in and reaping strong reward.  If you’re an SMB that has not yet made the leap, should you – and when?

First, recognize that mobile computing is necessitated by many things:

•   – Frequent travel by staff who need enterprise access “on the go”

•   – Requirements for situational access to data, such as in airports, meetings, etc.

•   – Companies that survey and dispense services at dispersed client locations

•   – Specialized apps for communications with, and services to, customers and prospects

•   – Marketing requirements, and associated apps

Then evaluate how you might leverage the following:

Targeting:  You can target your audience; on-the-go clients have mobile, and they want to engage.  That means you’ll want them to engage with you.  Once your client population is aware of you, you gain a targeted audience.  Also, your employees, solutions partners, and contractors have come to expect ready-communication and access – to information, to decisions.

Communication and support:  Apps help customers in their communication to you.  Your organization can collect data and feedback from them.  Questions, suggestions, and complaints can be addressed with ease and efficiency.  But further, your staff can communicate with the org too; whether on travel, in the field, or at the customer-site.

Marketing and promotion:  Apps are more essential than ever given the increase in the number of mobile users.  eCommerce requirements, payments, and the administration of shopping (such as layaways, “recently looked at” histories, and other sales boosts), make robust mobile enablements a must.

Customization:  Apps can be fitted to your specific missions, agendas, goals, products, and services.  Also, various features, preferences, and security controls are available for perfect fit.

Increased Earnings:   An obvious benefit of increased reach, targeted audiences, and more sales is increased earnings.

For SMB, exploring mobile is not an expensive proposition – at least as a first step.  Interview some mobile providers in your area:  They’ll meet with you for a free assessment of your environment, requirements, and goals.  From there, you can solicit some ballpark figures for forward progression and deliveries.

A mobile app, or suite of apps, is an investment – not just another cost.

The Social Network Next-door: Nextdoor

A rather interesting social network came to my attention – Nextdoor.

It’s neighborhood-based:  a private social network for your specific neighborhood.  You must use your real name with this one, and your real address.  It’s been around awhile, but is expanding to many more neighborhoods.

If you don’t live in a specific neighborhood, you can’t join that one, nor see anything in that network.  Also, if you move away, you’re no longer able to be a part of that neighborhood network.

In this type of social network, things are much more personal, and private info is more readily divulged and leveraged.  For example, you can post queries regarding neighbors’ experiences and recommendations with various tradespeople and professionals:  Mowing services, auto repair, doctors, dentists, etc.  If you pet is missing, you can include this in Neighborhood News.  Was a home burgled?  You’d be interested in knowing that.

Need a babysitter?  Giving away an old desk?  Need a bookcase?  These needs are “local,” and local resources exist.  It’s more targeted, personal, and perhaps immediate than something like Facebook, for example.  Maybe you’re looking to join, or post, a carpool.  How about starting a nanny-share?

Any downsides?  Boundaries are sometimes arbitrary – maybe some folks you’d like included are outside a certain zone that is normally an inclusion to your neighborhood in other contexts.  You can lobby the “Lead” of a neighborhood, if you like, in seeking a change to boundaries.

Also, sometimes condos or apartment houses get chunked as one entity/address, but that’s being worked on.  Be aware that if a network like this is ever hacked, your name, address, and any personal info you’ve posted might be accessed – a home full of valuable antiques doesn’t need a high-profile, for example.  iOS and Android apps are coming.

And now, I have to query my neighborhood as to where I left my bike after that block party…

City Lens: Cool App – and the future of facial recognition

Saw an interesting app with real appeal and practicality to boot.

It’s called City Lens, and it’s meant to give you an augmented view to what’s around you.  Simply by using your phone’s camera, you can display restaurants, shops, museums, services, etc., around you, with icons and text to tell you what each entity is.

Just tap the icon that’s overlayed on the view in front of you for more info.  You can share info with friends and also get directions.  Very helpful are reviews, hours of operation, contact info…  You can tilt your phone upright and receive options for List or Map view.

City Lens’ utility leads to a natural wonder:   Given the confluence of Big Data, new efficiencies in data density, rapid processing, the proliferation of public information on private individuals, and facial recognition technology, can it be long before you point your camera down a city street and have contact/background info on every person in view?

That day will come.  It’ll be awhile yet.  And… it’s kinda scary.

False Solutions have False Projects

The failure of VCF has been called the most highly publicized software failure in history – but, it’s not only the Federal Government that suffers from false solutions, and the resulting divide between critical requirements and delivery on these requirements.  Local cities provide examples, and lessons, as well, as does private business.

Washington, D.C. had an interesting project failure just a few short years ago.  They “paused” a project involving a mobile computer system for their fire department.  The District lost between $4 million and $6 million during the course of a year and a half’s mismanagement.  Part of the project’s confusion lie in the fact that there was a period where the fire department and the city’s Office of the Chief Technology Officer could not agree on who was in control of the budget – and therefore who controlled the project.  That represents a fundamental misunderstanding, and a pretty big divide.

The specific insight in this case is to recognize that there is no such thing as a “paused project.”  Once large-scale activity is halted, it ceases to be a project by any reasonable definition.  Once you stop work, you lose your timeline, all milestones, control of budget, and your lock on resources.  Evaporating too are expectations, definitions, and your anticipated implementation.  You’ve lost control of the solution – to issues, challenges and problems that the project was meant to address.  And remember – the so-called ‘paused project’ is berthed in a larger environment that does not pause its change.  There is no such thing as a “pause” within a managed, true, project.  What of the “go-live” date?  It’s lost – a new one must be established in these cases.

Once a project stalls, you have a strong clue that you may be trying to shoehorn a False Solution.

We don’t mean to pick on government here – we mean to help government – and you.  There are large-scale business and systems failures in private and public organizations large and small, and these failures are avoidable:

True solutions match fully exposed, and fully understood, hard business requirements – and they are implemented on target, on schedule.  Budgets are known, sanctions are tethered, and all aspects enjoy clear definition as to who controls various elements, to include the ultimate responsibility and steerage for the overall project.

Your Business-Technology Weave must execute proper exposure of need, proper planning, and carefully managed adjustments and delivery.  Properly executed projects, no matter how large, develop a self-reinforcing energy that lets all participants know they are progressing down the right path.  These participants have set their sanctions, set their sponsors.  They have aligned their resources.  All sides have exposed and agreed to expectations, are meeting true requirements, and are doing so with appropriately sized solutions.  Properly mounted projects are not constant pain, constant confusion, and constant rehash of issues that were supposedly decided at the outset of the project.  This is a crucial understanding for your BIT team, and any specific project management teams.  All levels of leadership and control in your organization should know what to do, and what to look out for and correct, at the outset of solutions and projects.

VCF Project Insights

The specific insight afforded here is this:  Once you find yourself “going back” on a project’s timeline to fix things, going back again – and again and again – you cannot, and never will, make timely forward progress.  The FBI could not have understood their “Where We Are” point of origin - tell me how to get to Washington, DC.  You must first know my point of departure in order to give me a route.  I must have a true route to get to the destination.

The FBI crafted a false route (project) with VCF, because they didn’t know where they were – their point of departure (their actual liabilities and requirements); and their “Where We’re Going” destination did not reflect a true solution to the business case.  This happened because of a failure to understand and expose true requirements.  Theirs was also a failure to set expectations in a language common to all necessary parties, in mounting a successful, properly defined, project.

Let’s learn something else here:  What differentiates VCF as a false solution vs. a poorly managed project?  VCF was in fact both, but here’s another important lesson.  If we take the Department of Justice at their word, we know that VCF had poorly defined (and evolving) requirements.  There’s no way to match solutions to poorly defined requirements – that is fundamental.  And, these poorly defined requirements were moving (evolving) – everything is changing.  So, any solutions that were being worked and attempted had to be divided from what was actually required: hence they were false.

We know too that there were “overly ambitious” schedules.  Schedules themselves are solutions; solving requirements for delivery of resources, for getting people together, for achieving consensus and progress, and for delivering solutions according to expectations.

An unrealistic schedule represents one that can’t be adhered to, and therefore is a false solution in and of itself.  Think of it this way:  Building an overly ambitious schedule is no different than relying on a calendar with 35 days per month.  Neither reflects reality, and will ultimately compel you to fail.

Divides spawn divides.  False solutions present themselves at all levels of the organization, within all strata and disciplines of a project, and often times small, not easily determined, falsities aggregate and contribute to the ultimate, overarching False Solution.

The conclusion for the FBI was that four years after terrorists crashed jetliners into the World Trade Center and the Pentagon, the FBI still did not have software for “connecting the dots”, and wouldn’t until Sentinel was finished and serving last year.  Even then, Sentinel suffered fundamental project flaws:  legacy hardware caused the system two critical outages.  Emplacing new systems on outdated infrastructure and architectures is an easily avoided problem – at least it’s a simple one in terms of understanding.  Match infrastructure to the overall solution’s requirements – it’s not mysterious.  Ensure spec of physical spaces, server requirements, storage, processing power, bandwidth, hosting, access points, end-user enablements, etc.

Quote of the day: 

I figure if someone at a party asks what I do, I can earn a valuable status upgrade by saying that I digitize tag clouds to e-enable infomediaries and engage data-driven long-tail folksonomies which harness rss-capable platforms and envisioneer cross-media functionalities. 

- Matt Labash

Next:  False Solutions can have False Projects

A Large Factor in Project Failure: The False Solution

There are many high-profile projects that highlight the peril of the False Solution, with attendant lessons for local orgs (yours) from which to learn.  Let’s consider the FBI’s Virtual Case File (VCF) tracking system that I mentioned a few articles ago, and its ultimate failure in a little more detail.

The VCF was intended to automate a largely paper-based system of case files involving potential terrorists, targets, and allied information.  Former 9/11 Commissioner Tim Roemer had characterized the FBI’s pre-9/11 case management as “index cards” and “typewriters.”  That’s pretty difficult to believe for 2001, but there ya go.  Clearly it was difficult to share and leverage intelligence in such an environment.  The FBI had a true need to implement a modern system that would allow agents and intelligence analysts to share information in the successful resolution of investigative work.  The overall goal of automation was a bona-fide need – the FBI had been criticized post-9/11 for “not connecting the dots” in time to prevent the attacks (essentially, they had an inability to manage and leverage dispersed content – information – intelligence).

Despite the necessary goal of automating the means by which to facilitate workflow, to search on information, to manage cases, and to provide reports, the FBI somehow managed to maneuver this project to a complete stall, and turned it into the ultimate “throw away.”  For, while VCF was deemed “critical” to the war on terror, after four years and almost $300 million the FBI ended up with 700,000 lines of bug-ridden code.  The system was so dysfunctional and far-removed from business requirements that it was scrapped.  VCF has been replaced with a new project, delivered late last year – Sentinel – which (happily) survived despite fundamental flaws in project management and execution.  But back to VCF and those lessons -

The U.S. Department of Justice’s Inspector General, Glenn A. Fine, released an audit that cited factors that contributed to the VCF’s failure.  Some of them were:

• Poorly defined and evolving requirements
• Overly ambitious schedules
• Lack of a plan to guide:
  • Hardware purchases
  • Network deployments
  • Software development

One could well ask: What served as their Business Implementation Team (discussed here in past articles), or did they even have something for that role?  Further, in looking at the list above, what was their Project Management Plan/Framework?  It was sorely lacking, or perhaps even missing.  It is actually quite easy to understand the FBI’s failure here: ever more effort was expended on going back and fixing things versus effort toward moving forward.  They lacked an understood point-of-origin, crafted a false route, and never reached their destination.

Next:  Some insights.

NP:  Jimi Hendrix, Hear My Train a’ Comin’ – 12-string acoustic version.

What are the Main Reasons for Project Failure?

Why do projects fail?  That’s a challenging question, especially for me:  None of mine ever do   :^ )

Well, not to sound too smug.   I’ve had elements of projects fail:  Missed milestones; sub-deliveries that weren’t optimal – that had to be re-engineered; angry blow-ups by key personnel in meetings (IT staff, vendor personnel, and… yours truly.  But in my case, it was justified; honest.  No, really…).  But on balance, most of the projects I’m involved with, whether as the lead, or a team member, progress quite satisfactorily and ‘go-live’ is on-time, and on-target.

Not to say that projects aren’t challenging:  Every single one I’ve been involved with has been very challenging at a minimum, and vary upward – that is the nature of projects, and project management.  But I know colleagues who have had disasters on their hands, and I’ve seen high-profile projects go awry too – newsworthy items.

What are the main reasons, and what can we do to mitigate risks?

1.  Scope and function creep:  When the project grows in scope during its actual course (we’ve “broken ground,” the project is defined, and the Project Management Plan [PMP] is supposedly firm and fixed), it indicates poor understanding of what the organization’s true requirements are.  IT and business stakeholders did not optimally engage, nor survey and divulge, respectively, all needs.  Now the actual project and its implementation is “teasing out” all of the undiscovereds, and adjustments are painful.  Be certain to do due diligence at the outset.  If you have to delay a project’s start a bit, and do more survey, it can be frustrating – and justifying to higher authorities can be uncomfortable.  But it beats a hobbled project once underway – by a long shot.
2. Unrealistic and unclear objectives:  Related to the above, perhaps business asked for too much, and it’s having a deleterious effect on the budget.  Maybe business asked for a lot, with all correct IT warnings and caveats expressed and in place; nonetheless, the plan, timeline and people are stretched.  Worse than scope and function creep (whereby you can at least spec something to fit an area that wasn’t exposed as a need), is an unclear objective:  Here, a delivery is made to a “false target” – and you have to start over.  Spec requirements and solutions very carefully.
3. Lack of commitment:  Whether the Project Manager (PM), stakeholders, the IT team, or the vendor, commitment is essential.  Even if elements on the overall team don’t believe in a certain area, they have to contribute as directed, and put best efforts toward the total solution.  Governance and other leaders have sanctioned the project, and it’s full speed ahead.
4. Poor methodology:  Practice good project management.  Regularized survey of progress, accurate reports, early adjustments (to effort, milestone supports, attitudes, etc.), are essential.  Also be sure to keep management apprised of problems when difficulties exceed the PM’s authority for rectification.  Same for team members – if there’s a problem whose solution involves things above your pay-grade, get help.  If you are “management,” foster an open-door and dialog culture, so as to encourage early warnings, for early corrections.  Don’t tip this area into inefficiency – reportages must be mature, made through proper channels of escalation(s), and concern stuff that cannot be ironed out at lower levels – don’t pass out crying blankets.
5. Poor communication:  Make meetings count; have enough, but not to the point of diminishing return – have something important to communicate, and track the project’s progress.  Reports and evaluations are communication too – survey all areas of the project’s efficiencies and potentials for problems.  Get on necessary tune-ups early.

In the meantime, remember to maintain solid support to present systems and statuses, as you drive toward the golden solution.

NP:  John Coltrane; Blue Train.  Original vinyl (of course).

IT Staff Member Refuses to Progress – One bad apple…

A colleague entered a new position as Director of Information Technology.  A prestigious association in the Washington, DC Metro area – the specific city will remain nameless.

The association had their own building.  He had a corner office on the top floor – wall-to-wall windows on two sides that were nearly floor-to-ceiling, with a great view.  Nice big conference table right in his office.  The kitchen was a couple floors down, but, hey, maybe they could move that.

Anyway, everything’s rosy, right?  Lots of challenges, but we always have those in IT:  The association management system (AMS) was on the cusp of a major upgrade (huge – the vendor was even completely re-titling the product), and there were some staff currency/training issues.  Ah, those are routine – always someone who needs this class or that, or a boot to get current.

But over the first weeks and months he discovered something very bad:  The “senior” programmer… um… didn’t do anything.  I mean, she didn’t do anything… IT related.  Oh, she had her routine.  She floated around the building, making her rounds and chatting.  She attended meetings.  She contributed in the sense that she always had an opinion – generally not worth anything, but she liked to sound officious.

What was happening was that she passed any work that came to her, to a junior programmer – always the same guy.  This man was very milquetoast, and didn’t speak up.  He was overloaded, but he suffered on, afraid to speak up.  How long had this been going on?  My colleague couldn’t know, but he knew that the senior programmer’s skills had completely atrophied to the point where she literally couldn’t contribute in the modern environment.

The IT Director did what any responsible supervisor would do:  He counseled the senior programmer.  He directed her to schedule herself for training.  When she didn’t, he selected an initial course, and directly told her to enroll in it.  She didn’t.  He then talked to his boss about things, and was told to “handle it.”  Next step?

The timing yielded an opportunity to document things in a formal review – it was due.  He drafted things very carefully, and overall, the review was quite accurate – but generally negative.  It had to be if it was going to be a true review.  He was directed by the Deputy Executive Director of the organization (the #2 person) to re-write it.  He did so under protest.  It still had a mild version of the need for training, and stepping up, and making a more robust contribution.  But it really wasn’t motivating.  She did not change.

Why change?  She had political cover, as it turns out, in the organization.  It also turned out that she had wanted the IT Director position.  She felt it was her due, and that she had been denied.

After enough time had passed to make his resume look good, my colleague left the organization – for a better org, a better position, and a better salary.

Meantime, the organization suffered a situation whereby their in-house programmers could not keep up with the AMS, its mods, and its progressions.  The org also lagged in its infrastructure upgrades.  The Network Manager, a great asset, left and was replaced with a lesser person.  Other quality personnel left, women and men of character and quality,who were difficult to replace…

Their IT shop is now pretty lousy.  It’s propped up with expensive outside counsel and support players.

One bad apple can spoil the whole bunch.  To the senior executive class, directors, managers, supervisors:  Rate fairly, accurately, and ferret out those who do not serve.

Lead by example, and hold those you rate accountable.  Praise and promote those who are due.

Maintaining and balancing an IT department and its service to business is not always easy, but it is absolutely necessary.

Recommendations for Managing Vendors who are Routinely Late with Deliverables

Perhaps some insight:  Does the vendor have a habit of re-scheduling meetings?- or, cancelling and renegotiating regularly-scheduled recurring ones?  This would be a strong clue that they are fighting fires, and missing milestones with other clients – and your project is in a competition for their attention with other lagging projects.

As concerns ANY vendor or solutions partner, be sure to meet at their location from time-to-time – not just during an initial vetting of any particular solutions partner – but go to their site for meetings throughout the project – and judge the general culture and “feel” of the place. Does it look like a harried environment?  Or, hopefully, are people focused, balanced, and seemingly productive?  If the site looks and feels like a stressed environment (beyond the usual healthy tension), then you’d better re-evaluate your preferred vendor list.

In all cases, determine what caused the missed delivery(ies).  Execute the clauses in all relevant contracts that trigger penalties for missed work (such as rebates, discounts, etc.) – hopefully you have those, but if not, be sure to craft future contracts this way.

Is the vendor solely to blame (or perhaps not at all)?  Are there people or departments in your organization that are  not submitting key deliverables to the vendor on time?  You can’t penalize the vendor, or negotiate discounts, etc., if that is the case.  Find the point(s) of failure and correct.  As to the core of projects, stick carefully to milestones and statement/scopes-of-work.  If there are change orders, and negotiated additions to the original project, make adjustments in your project management software and in reports, so that changes to the speed and direction of the “river” of the project do not show up as budget overruns and missed deliverables – it is not fair nor accurate to classify adjustments and additional work that way.  (However, if poor project planning on the part of your organization exists, perhaps in the form of a poorly defined project, and related Request for Proposal [RFP], then this unfailingly results in a good-faith vendor Proposal, but one with poor match to your true business/IT requirements.  The org suffers, and is at fault, and missed deadlines and a wobbly project should reflect in reports, so the org can learn and not repeat these mistakes).

If the vendor is truly remiss, then pilot the current project to successful conclusion as best you can, and write this vendor off if possible.  If it’s a project that involves a central solution to the enterprise, like a core-business system, and it’s a vendor that’s virtually interwoven into your enterprise, then you’ll have to do the diligence with contracts and accountabilities.  Possibly get some measure of your senior executive class to engage with theirs, in order to set some expectations for future engagements and progressions – and hopefully fulfillment of expectations for true adherence to milestones, project expectations, and deliveries.

When ironing out difficulties, maintain maturity, focus, transparency and communication.  Learn from difficulties, and use them to improve contract documents, project management systems, early warning indicators, management of personnel, and reportage.