Top 5 People Management Skills

Everyone can benefit from a periodic self-assessment of their ability to manage and motivate people.  For those junior readers, you can use this to assess the effectiveness of your superiors.

Let’s keep in mind throughout that people like to be led, as opposed to managed.   (Recognize, though, that there are elements of work, particularly IT, that are rote checklists and rather rigid strictures – and sometimes there’s not a whole lot of room for imagination.  That aside…).  People want someone to admire; they want to observe someone and work for someone whose skills and leadership they can emulate.  I know I do.  It’s pretty basic:  The more collaborative a team, including the boss, the better.

So… lead.  And utilize these effectively:

1.  Communication Skills:  Communicate as often as necessary.  Don’t leave people to guess; provide enough detail and oversight – but don’t smother people.  No one wants to be micromanaged.

-  Writing:  Ensure your department, job, etc., has enough formal documentation to cover the bases from routine absences through emergencies.  When preparing documentation, as well as ad hoc memos, e-mails, instruction-sets, project management plans/frameworks – anything – always perform a final edit as if you are reading through the recipient’s eyes, with all of their biases, knowledge gaps, points of ambiguity… and write to inform to that class.

-  Speaking:  When addressing groups, speak up – project to the back of the room.  If you’re leading a room, lead it.  If you’re participating in a conversation, try not to interrupt – unless you are absolutely certain someone is in possession of old information, and you have updates.  Solicit team members’ opinions and input.  Be collaborative.  Be inclusive; try to draw shy team members out a bit – good ideas can hide in quiet people.

-  Listening:  Shut up once in awhile; try not to be too dogmatic; value each member’s contribution to the degree that is practical.

2.  Interpersonal Skills:

- Cooperation:  Try to get along; be pleasant.  Leave room for compromise when possible.  If you must disagree, go on record as to your reasons for disagreement; if something goes south, you needn’t trumpet your prior warnings – rather, you’re protected by virtue of having been prescient and wise, and that’s good enough.

- Motivation:  Provide incentives if you’re a leader.  Incentives can be as simple as praise when work is performed well.  Don’t overpraise.  Sincerity means that praise is occasioned, targeted to something worthy, and achieves a measure of recognition (beyond the person/persons praised; a mention in a team meeting, an org-wide meeting, to a member of the senior executive staff, board, etc.).  People will aspire to further praise in the future, and quality is engendered and maintained.  Of course, if you have bonusing at your disposal, you can employ that – but the simple things work in the course of the day-to-day.

-  Supporting:  Be supportive.  Give your people the resources they need – to include budget, time, and other staff.  Be positive for them, so as to inculcate their positivity.  Be available to listen.  Support also means being firm when necessary.  Don’t give space to empty whining and ruminations.  Kick people back out into the arena:  “We all come to work in our big boy/big girl pants – and that includes me.”  That statement works wonders.  Man-up.  Woman-up.

3.  Planning Skills:  Know how to plan, and thus know how to deliver.  Be able to solve problems; know what needs to be done, who to go to, and how to achieve consensus.  Be able to analyze issues, make accurate diagnosis, and get things moving; keep them moving.  Strategize effectively, and work with others in this regard.

4.  Organizational Skills:  Closely related to planning, know how to coordinate tasks, gain cooperation from allied people and interwoven tasks; know how to set goals (be realistic; know how to measure progress; know when and how to boot people in the butt when necessary); handle details.  Know your optimal level of detail:  Utilize your staff for the proper administration of details.

5.  Management Skills:  Mentor; teach; lead.  Know how to solicit input; know where to go for best information.  Make firm decisions.  Set an example in all regards:  Be on time; be on balance.  Impart knowledge.  Acknowledge knowledge.  Give people their due.

When managing people, ask yourself some questions:

1. What are they thinking?  What are their perspectives…?

- Why are they doing this?  Examine behaviours – maybe staff needs additional information; maybe they feel their ideas aren’t getting across; look for motivators.

2.  What do they need?  Don’t overlook the general or the obvious:

- Detail-oriented people need details

- Tech people need tech info

- Business people need answers that address the bottom-line

- Satisfy needs that hinge on “outside” factors; for example, a person might need a deliverable from another team in making their committed delivery, etc.

3.  What are people’s strengths/weaknesses?  Position people on your team to perform according to their strengths.  Examine weaknesses, and handle through training, re-assignment, mentorship.

NP:  Fairport Convention:  Traditions.

Project Manager Can’t Manage: What to do?

This situation came up recently and it happens more often than you might think – a Project Manager (PM) who can’t manage very well.

If you’re lucky the project staggers forward and meanders to a conclusion somewhere in the neighborhood of expectations.  This is kinda one of those “bad boss” scenarios – after all, on the project team, this guy or gal is… in charge.

This person is going to make and adjust assignments.  This person likely has input to your next rating if you’re a member of his/her project team (either as a temporary project assignment, or if you’re a permanent member of this person’s staff).  Also, you have to negotiate with this person regarding resources, timelines, and deliveries.  It’s nice if the PM is in your corner during the crunches (and vice versa), because you also have to negotiate regarding stakeholders and their expectations; both business people and other IT folks.

Oftentimes, you may find yourself exasperated – ‘How did he (she) get assigned this project?!  He (she) has absolutely no talent for it!’  I’ve been involved with teams like that.  I’ve had to rescue a few after the PM dropped the ball too.  But assuming things aren’t falling off the edge of the earth, keep a few things in mind:

1.  If the PM has clear sanction, and things aren’t so fouled up that they’re likely to stick on the project, be certain to get along – whatever it takes.  (Well, short of illegalities, HR violations, or putting your own esteem in a completely unrecoverable position, that is).  But try to keep the destination in sight:  The project won’t last forever.
2. Flatter the PM – just don’t be too obvious about it.  ‘I need your advice…’, ‘I heard about the time you…’, ‘I thought some similar latitude might work here…’ – be imaginative.  Get on the PM’s good side.  To do that, find something, anything, that you can play up.  Too often, the crunch of projects leads everyone into an unremitting, gallows-humor, negative zone.  Be different and see what it gets ya.
3. Buck up your teammates on the project.  Not to be a Pollyanna, but be positive.  Also, develop a reputation out in the business sphere, and do what you can to allow that to leach into the tech side of the project.  Once you have a reputation for positivity, a “can do” attitude, and you’re seen as a winning personality out in the business sphere, it will be awfully tough for anyone in IT to give you a hard time.  Bet.
4. If you’re 100% something needs to be done, is going to work, and I mean work like gangbusters, and you can get it done – do it.  There’s an old expression:  It’s easier to ask forgiveness than to ask permission.  Nothing succeeds like success, and everyone once in awhile just needs to do it.  Know what you’re doing though.  If someone takes you to task for exceeding the limit of your lead, play dumb – be sure you’re good at playing dumb – look sincere.
5. The PM may suspect him-or-herself of not performing well:  This is a really bad situation.  PMs (and any leader in these situations) become overbearing, trying to prove their “competence” and “confidence.”  Don’t do anything to make the PM feel insecure or small, or things will really become difficult, with a short-tempered micromanaging PM the result.

Bump the project along.  If you have a strong project team, and there is trust among the members, then get a little aggressive – everyone can start to push – there’s strength in numbers.  I’m not saying to go behind the PM’s back, but push the envelope.

Hey – ya gotta do something, right?  Stay within the law, don’t step on any feelings if you can help it, and it helps to remember the alternative:  Watching a lousy PM maneuver the project out into left field.  Don’t let that happen.

Of course, the PM’s boss is likely to notice something awry.  If you ever get called in by a level of oversight that is above your boss (project or otherwise), be factual.  Don’t sugar-coat anything, but also be very serious and empirical.  Give examples.  Don’t come across as a back-stabber (even though your opinion has been solicited).

Once a specific level of management is soliciting opinions regarding a middle-manager, a change has pretty much been decided upon, so the gentle push of truth will serve here.

NP:  The Doors:  Essential Rarities.  Rest in peace, Ray.

Certs Redux

Saw a question in a forum that went a bit like this:

‘What entry-level certifications does one need to help launch an IT career?’

There was no shortage of advice:  CompTIA, A+, Network+, CCNA, Windows Operating System Fundamentals, Windows Server Administration Fundamentals, Networking Fundamentals, Security Fundamentals, Software Development Fundamentals, Windows Development Fundamentals, Web Development Fundamentals,.NET Fundamentals, HTML5 App Development Fundamentals…

It was a good while before someone (not me) suggested saving some money and doing some self-training and subsequent testing.  Going after certs can be expensive, and I often wonder if it’s not better to just jump into some college courses at night – do you have a branch of a major university near you?  Or perhaps a good junior or two-year college?

If no one is springing for a four-year degree for you, and you can’t afford full-time college, and you have a logical mind, enjoy problem solving, and interview well, then get on a HelpDesk in a robust enterprise environment.  That’s your foot in the door, and you can go anywhere from there if you know how to “sell” yourself.

Once you’re working full-time in an IT department, you can send yourself to school at night, and go any direction you want:  software programming, network engineering, Cloud development, applications development, mobile…

One good piece of advice offered in the forum:  Don’t specialize too early.  You really need a robust grounding – everything fits together into the same overall puzzle, and it helps to understand all the other pieces, if only tacitly.  An awful lot of people in IT (and business) are myopic thus lousy overall fits to the true business at-hand.

Get on a Help Desk, sit in IT meetings, look around, see what turns you on and go for it.

Worried you might be too good a HelpDesk staffmember?  What happens if you get stuck on the Help Desk?  It happens.  Remember this:  The best IT people move around.  You have to.  The market is going to take care of you.  Get out there.  Why work in a critical and robust field like IT if you’re afraid to move on… and up?

In fact, I’d say during the early part of your career – the first decade, certainly, you only need stay in a job 2 to 3 years – unless you really, really, really, really like it – and are willing to risk stagnation.

‘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.