Posted on

Applying the Socratic Method to “Problem Solving” in Project Management

socratic method

When utilizing the Socratic method, an instructor asks her pupils a series of questions designed to stimulate more complete thinking and insight. Applying the Socratic method forces you to look more closely at your ideas, beliefs, and assumptions.

Did you know, more data has been created in the past two years than in the entire previous history of the human race?  While the ramifications of having access to this much knowledge are still to be determined, one thing is clear: we have (at our fingertips) access to an unprecedented amount of data.

The key point of the Socratic method (that we apply to our project management systems) is using cooperative argumentative dialogue to stimulate true critical thinking. Put another way, we don’t let opinions and non-facts stand in the way of making the best decision.

In web and software development, a lot of tasks that seem like much simpler tasks are often found out to be more difficult.

Take this example of updating the design of a website:

We’ve decided we want to replace the logos, and update the website colors and schemes. We know it’s just reorganizing the home page, updating a few logos and changing the text around.

At first, this seems easy, we think it’ll take a few hours. We don’t need to do any research to see how long this took in the past (accessing our own data) or how long it took competing companies (accessing available data on the internet or other resources). We already “know.”

So we compile the necessary materials (new logo, branding guide, fonts) and we begin. Unfortunately, we find out after two hours the new format takes longer than we thought. We told the boss it’d be ready by the end of the day, but now it looks like it won’t be ready until tomorrow.

Tomorrow comes around, the new look still isn’t ready. It turns out the designers didn’t properly account for mobile websites, and the new email templates are horrific looking in Outlook. Chaos ensues.

This takes all day to correct, and the next day begins.

We’re now on the second day of a project that was supposed to only take an afternoon, and the boss mentions “even Amazon Prime could have delivered it by now!” Developers begin to worry if they’ll see their wives again (play Battlefield 1) and designers are blogging furiously about how incompetent programmers are.

No one took the time to plan the projects, with a focus on moving beyond underlying presumptions (“it’s just a simple redesign”) and finding out the real issues (“this wasn’t properly planned for across device and in different platforms”). Nor did anyone check the data we have readily available to set proper timelines.

Larger problems have a nasty habit of disguising themselves as “just a few more hours of hard work,” and unrealistic deadlines (whether hindsight or known) cause unnecessary stress and fires to put out. Couple that with the standard human ego–especially when dealing with “experts” in an industry–and you have a perfect recipe for unnecessary stress.

Enter the Socratic questioning method, and we now have a solution for solving all of our tasks:

  1. Break each task into pieces, elements, and components.
  2. Look for relationships between the components, and missing information. If we need to add a new logo to the website, do we have all of the logo sizes and files, or is it buried in some PDF?
  3. Add the simplified as tasks within the Task Tracking software (we’re currently using Asana).
  4. Check prior tasks within HubStaff (this is a  tool we use to track how long it takes people to complete a given task). If we’ve never done a task like this before, spend some time on the internet or with a trusted colleague to get a better estimate and possible task-outliers
  5. Ok, now go back and actually read all of the materials and provided project tasks. Seriously, a number of tasks that aren’t done properly because someone skimmed a PDF (“Hey, I’m the busy CEO, I don’t have time for reading memos”) is baffling. Spend 15 more minutes planning a task and save yourself hours of back-and-forth.
  6. Create a video or have a meeting to review all the tasks, ensure all developers and people responsible for the task ask the important questions (and are ready to identify and immediately point out potential constraints, bottlenecks, or failures”
  7. Check the business logic and make sure there is a point for doing this. A lot of time is wasting on people doing well what needs not be done at all

It seems there is an accepted form of professional blackmail, where experts are expected to have the answers to a question at any given moment. Let’s be honest and acknowledge this is rarely the case. Using the Socratic Method for problem solving, while taking a few extra hours, is bound to save days and weeks of headaches and “delayed projects” from affecting other areas of business.

Posted on

The Pains of Developing an MVP and How to Overcome Them

The fabled MVP has become the new sexy word to throw around when it’s time to develop a new application, company, or product.

MVP (or minimum viable product) is meant to achieve a concept called Product Market Fit as quickly as possible. The MVP allows for small improvements based on real feedback—as opposed to  the traditional school of thought,  which is to try to launch publicly with what we think is our final, perfected product.

Think the quiet and inexpensive growth of Airbnb vs the giant release of the first iPhone.

While the concept of the MVP is a great concept, and it does work very well when executed properly, proper execution is extremely difficult. I’ve found there are generally 3 killers:

Ego Trumps All

A lot of people’s ego get in the way of the process. They want the software or the website to be “perfect” in their eyes, without really a care to the consumer.

When this is brought up, the response is usually, “oh, I know what the consumer wants.” Followed by endless meetings trying to justify why no one is buying the product or using the fancy new app.

The problem is a lot of people have issues with putting something out into the wild that they don’t deem as perfect. They chase down rabbit holes looking at issues that defeat the whole purpose of doing the MVP process in the first place.

A graph at the end of this article shows the concept of MVP a bit better too.

I’ve seen several situations where the owner of a start up developing an MVP basically ignored all of the consumer feedback (either justifying how it wasn’t the right client, or justifying how it was a one-off that wouldn’t affect the market as a whole). Instead, he only focused on his experience with the application, ruining the entire product along with it.

The Importance of Money & Time

A lot of times people hear the fantasy stories and the “cases” of Airbnb, Snapchat, or similar apps and hyper focus on the fact that it was low cost or even free (outside of time invested) to develop their app.

They then lose focus of the fact that:

  1. The exceptions are not the rule
  2. Their app isn’t nearly as revolutionary or “new” as they think it is (and definitely isn’t new to the market)

Businesses run on money. Even those one-off stories required VC or angel investment soon after they got noticed in the market. Servers need to be maintained, employees need to be paid, customers need assistance, and so on.

It’s So Misunderstood

The point of this is really quite simple:

You get a basic working version of some feature or product to the end user as fast as possible, and then continue doing that. You’re collecting validated learning experience to build consumers exactly what they want.

It’s also a methodology, not just a single product. It’s constantly working on improving and upgrading the product to fit the consumer need. This meme does a great job of explaining:

Original Image: Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable by Henrik Kniberg

Posted on

Why Your Software Developer Needs To Go To Sleep

“Well, you really want your IT guys [or department] to be the kind of guys that don’t have a life or girlfriend. They just sit behind their computers all day and night.”

Um, okay.

Time At Work Does NOT Equal Productive Output

I was sitting on my couch reading the other night (okay, I was playing Madden) when a solution to a software problem we’ve been trying to solve suddenly popped into my head.

We were trying to think of the best way to create a set of CSV files for a partner company to access to track some basic data entry.

While I was sitting there debating whether or not Drew Brees was going to cut it as my new franchise Quarterback, I suddenly realized that we shouldn’t be doing this with a CSV file at all, but rather (and contrary to task instructions) with a member portal.

Does this mean I should just play Madden all day? Unfortunately, no. However, if I hadn’t taken the time to rest and give my mind a break, we would have likely kept going down the road that we were “supposed” to, which wouldn’t have created the best solution for the client or their partners.

24/7 Connection Doesn’t Mean 24/7 Work-Life

This one has been written about in countless articles and books, and is becoming a more popular topic:

The obsession that our culture has with work is having a significant impact on our livelihood, families, and workplace productivity.

Just because we are now connected 24/7 doesn’t mean you should expect to hear back from someone within minutes at 9 pm (or, even 9 am).

Oh, but this issue is urgent?

In the excellent Phoenix Project book, the author says it best:

Something seems wrong in a world where half the e-mail messages sent are urgent. Can everything really be that important?

Most “urgent” issues that come across my desk are only “urgent” in the same sense that makes us pay a little more for overnight shipping.  Just because something is “wanted now” doesn’t mean it’s “urgent.”

Knowledge Workers Should Work Fewer Hours

What ends up happening is that this “developer” (the one with no life) is in front of a computer for 12 or 14 hours a day, but that doesn’t include:

  • The 90-minute lunch
  • The 2 hours spent on forums, Hacker News, Stack Overflow, or (more likely) Facebook
  • The hour-long discussion about whether or not Russia did hack the election

In a famous 1993 study of young violinists, Anders Ericsson found that the best ones all practiced the same way: in the morning, in three increments of no more than 90 minutes each, with a break between each.

He discovered the same pattern among other musicians, writers, chess players, and athletes.

I’ve found this (or a variation where you work for 55 minutes and take a 5-minute break, and then an at least an hour for lunch) is the best form of productivity. Fewer hours, but hours where you work 100% of the hours (no distractions because Aunt Sally lit up Facebook with a new fake news article).

I know, the new credo is that we need to work 80 hours a week, and be connected 24/7 in case “something comes up.”

Companies and countries encourage this mentality (more work means more productivity right?) while completely ignoring everything we scientifically know about productivity and performance.

We never challenge an executive or (really any worker) when they exclaim they’ve “worked 80 hours this week.” We accept them as someone who must be a hard worker and ignore the fact that it likely means quite the opposite.

Instead of worrying about hours in, I’d like to see a work culture that is concerned about the productivity during hours worked.

 

 

Posted on

Why Software Projects Make People Pull Their Hair Out

There was a study done in 1995 (22 years ago as of this writing) that concluded:

  • Only 16% of software projects were successful
  • 54% were challenged (cost overruns, budget overruns, or deficiencies)
  • 31% were outright cancelled
  • The average project runs 222% late, 189% over budget, and delivers only 61% of the specified functions.

Failure has become the IT norm. Today I want to discuss some of the reasons why, and in a follow up article, I’ll discuss my life mission to do something about it.

No Time

Most software projects I’ve quoted or started had a deadline date that was decided well before the project starts. 99% of the time, this is an arbitrary date of when “it’d be nice to have it.”

OR, a project is started with the intentions of “doing it right,” but a few months into the project there becomes a sudden need for it “to be done now.”

There’s an excellent quote from the Mythical Man-Month (a software development book written in the 70s):

But false scheduling to match the patron’s desired date is much more common in our discipline than elsewhere in engineering.

If anything, this has gotten worse in the age of iPhone Apps and overnight shipping. People are set on just deciding it’s time for a project to be “due.”

No Budget

A lot of projects don’t have proper budgets allocated to them. Without knowing the specific requirements of a software, it’s impossible to determine how much it could cost. Much like home remodels or other labor intensive work, the cost of a software project is based on how long it takes the geeks working on it to complete it.

Companies go in looking for the lowest possible price on the project, and ignore the suppliers (generally the more experienced ones) who have strong cases for why it costs as much as it does.

Worse is when the budget runs out partially through the project. It’s important to ensure that the budget is in place to retain and optimize the solution down the road.

Bad Communication

Clients often complain about the “disappearing developer” act that is very common in our industry (as well as graphic design). More often than not, the types of developers or designers that disappear are the ones that weren’t that professional in the first place (see, “No Budget,” above). Hiring the cheapest and lowest common denominator generally comes with lower professionalism and dedication.

We see quite the opposite, which is the “disappearing client” act.

A project will go well and we have your attention for several weeks, maybe even several months. Then, suddenly, our requests for testing or meetings are ignored.

You’ve become busy with another project or company emergency. The budget came in a lot lower than you expected, or you had delays/issues in other projects that needed your attention.

This, of course, is not the largest issue. We understand that things happen (I own a business myself and frequently have to delay my vendors while dealing with important issues).

The problem comes when all of a sudden, these lost weeks (or months) show up at the last minute with an urgent need to rush the project as soon as possible, which then creates:

No Focus on Quality

When there’s a haste to deliver the software or website, quality will suffer. Things won’t be tested or documented properly, and solutions will be rushed out. While this may save a couple of hours or even a couple of days, it always ends up in weeks (sometimes months or years) worth of delays.