The Art of Finishing

I relate heavily to the author's dilemma. My projects span from math, to programming, to pinball repair, to amateur radio, to gardening, to mycology, to who knows what else. I personally enjoy the process of bike-shedding and endlessly exploring the solution space for a problem. That said, there is a point where you need to make hard decisions and button up projects.

As long as I don't care what project gets completed at what time, I've found a little trick to broadly move the needle. I jokingly call it "Sol's fast five" but the name is actually pretty on point.

I take a step back, look around me, and pick out the first five things I can reasonably achieve in less then a day prioritizing things where I have all the tools and materials at hand. These 5 things are never entire projects, the goal is to maximally decompose the projects until each action is as close to trivial as possible.

Once I have my list of 5 things I stop thinking about anything else and strictly work towards those 5 goals. There is a sense of relief in having reduced the scope and the tasks tend to be finished very quickly. Checking them off the list always feels good.

Once I have completed my 5 items I start a new list and pick out the next five items. This can feel like a huge reward.

I've used this system to great effect in the past few years.

Or, you could stop beating yourself up about it and reframe the whole activity as a creative release. Nobody else cares if you finish it, why should you? My neighbor died with a project car parked in his driveway. It had been there for years. Every so often he got out there and worked on it with his grandson. Who among us would call that time wasted? Why not dust off Project Foo on a Saturday afternoon, and just tinker with the fun parts?

I used to find myself under the effects of this curse as well, so I would recommend the author look into why he embarks on such a thicket of unfinished side projects. In my own case, it boiled down to a mix of several imperfectly aligned factors:

1. Genuine intellectual interest

2. A desire to improve particular skills

3. A vague sense, acquired by osmosis, that industriously working on side projects during one's free time is what a Real Engineer does

Disentangling these motives and identifying a clear primary drive behind each project clears up the "hydra" feeling wonderfully, as most of the heads simply disappear once you realize that you never had a strong reason to pursue them in the first place. (3) in particular is often merely the self-castigating whisper of the internalized "should" rather than a valid reason to embark on a long and open-ended project.

I think it's worth differentiating between personal projects done to learn or just for interest, and those that are trying to accomplish something. If I do a project for myself to try things out and learn something I don't feel any pressure to finish the project. Once I've learned something or had some fun, who cares if it's "finished" or if anyone else will use it. On the other hand, sometimes I'll pick up something interesting that helps a friend or family member, or just that I need for myself, and there I'm pretty careful about scope. If I can't finish it in a couple weekends I'll look for the closest commercial solution unless it's a major once-in-a-decade passion project.

I suffer the same problem. It is all about conserving mental energy. The way I see it, each person has 2 different mental power gears. A high power one, that drains you and makes you excited at same time. You need this for planning and thinking big or learning about a new tool. And a Low power gear that allows you to fix bugs and create a small feature for a known tool. We mostly use this low power gear in our daily life, in meetings, while driving or preparing coffee. The high power gear is used sparingly, when we can't sleep at night because of an idea, when we try to learn something new. it is exciting, but draining and painful at the same time. We want to do it again only after forgetting the pain.

I think proscratination is because we use a high power gear too frequently, we are exhausted mentally, and it is too painful. so we say let's do it later. But what if you have a small task that does not need a lot of thinking to do? something not painful? Well this is easy. I can do it. The trick is, it needs to be easy. you should not waste 1 hour to set up your environment to be able to start. it has to be easy.

So to advance on a project, I need to make sure I always have low energy, easy tasks ready for me when i am not in my mental capacity to use my high power thinking.

It is as if I am 2 persons. a developer and an intern. you need to make sure there is enough easy tasks for the intern to work on. You have to accept this about youreself

Dont waste days planning and creating issues for youreself. This is too draining. you need to write the big plan only and make sure you have few tasks ready. not all of them defined from day 0. do a big planning every 2 to 3 weeks (looks similar to a sprint)

It is all about conserving your mental energy

What if personal projects are not meant to be finished? Journey and destination and all that? Perhaps for some it's more about the endless noodling about and whittling away bits and pieces, and a "project" is just a convenient excuse do do it?

Finishing is super important. Just focus on completing a version 0. Then, you can improve it if you feel like it. It doesn't have to be perfect, just finished under a reasonable timeframe.

Not finishing and endlessly moving from one project to another is bad because it prevents you from making meaningful progress. You end up spreading your efforts too thin and never see the results of your hard work. This can lead to a lack of closure, decreased motivation, and a cycle of unfinished projects that never reach their potential. Moreover, without finishing, you miss out on valuable feedback and the sense of accomplishment that comes from completing a project, which can be crucial for personal and professional growth.

I’ve mastered this. I’ve finished 12+ projects in the last year. 1 even made money.

How? My projects are tiny. If you’re building solo, you have to tackle projects reasonable for a solo dev.

I primarily build chrome extensions because the simplest ones can be finished in one night, and the hardest a month or two. It’s frontend only work, so you minimise the project surface area. I’ve only been building them for a year but I finish all of them.

And I focus on getting an MVP out, and only polish if I can be bothered.

Now that I’ve mastered the finish, I’m moving on to different projects:

- API only projects - Scripts - NextJS projects (simple backend) - static pages

Perfectionism is the enemy of done. It’s a good principle to keep in mind when you’re working on any project so that your valuable time isn’t wasted.

Sometimes it is fun to explore something and sometimes it’s better to never start. I have a running list of ideas i will never work on until the opportunity of time and savings align.

I’m not sure if it’s common but i heard this quote from an entrepreneur: “There’s nothing worse than a mediocre business “. A bad business will die of its own, a good one sustains itself, and a mediocre one grinds you down.

I find it’s easier for me to finish physical products, like woodworking, rather than software. I’m building a door right now for my patio, and let me tell you that it’s next to impossible to redo the design of a piece of wood once you’ve milled it down to a certain size or shaped it, so you learn to think very clearly about the goals of a project and the design before you cut anything. In my off time, I don’t want to endlessly struggle to finish things, so I don’t do software. I also do simracing, which also has bite sized goals, like “improve my safety rating to X” or “post three clean laps on a new track”. Though, no matter the hobby, you have to be able to set a small goal and achieve it pretty quick, so I’ll tell myself “just finish the tenons on these frame parts rough, then you can finish them tomorrow.”

Edit: To add, I don’t expect perfection from my wood projects. There are gaps and cracks, I use the wrong wood or don’t orient the grains properly, etc. That doesn’t matter, though, because everyone who sees my projects are amazed at my skill, partly because they don’t know where to look for the errors, but also because just finishing anything physical like a door represents a great feat that most won’t even try. It’s different for software, there’s a greater expectation for some reason, or perhaps a virtual product isn’t as tangible as a physical one.

Those strategies for finishing projects are exactly why I’ve been running a six-week group[0] where we all work on our projects together.

Setting goals, time-boxing, accountability, celebrations — it’s all built in.

I’ve definitely found that during the 6 weeks that I find a laser focus on what I want to do and how I want to do it.

It adds a fence to the green field project, so to speak.

Highly recommend building alongside others, if you haven’t tried it yet.

[0] https://lmt2.com

Great description of the problem. I enjoyed reading it, it’s almost like prose, great writing.

The solution I’m afraid is only one: solve smaller problems. There is no way a single person can solve a team’s problem as a side project. A small problem does not mean small codebase. It means small as in: focused, simple pain, simple solution, low amount of open questions.

Yes there is value to all of the other strategies mentioned. But if you want the root cause and the solution for this hydra effect it is the one I mentioned.

If you were born anywhere in the 80s, you might have spent the 90s and early 00s building side projects that you actually finished and felt no remorse over. That’s because scope was naturally small, problems were more focused, and there were multiple order of magnitude less options to choose from (in any domain: programming languages, libraries, interfaces, user flows, business workflows — everything was less)

A phrase that has stuck with me over the years is:

  A man is measured by the things he finishes, not by the things he starts.

Since taking that to heart, I've never really had a problem with finishing things. :)

Similar to "The Cult of Done Manifesto" (2009) https://designmanifestos.org/bre-pettis-and-kio-stark-2009-t...

Just not enough time in the day. Some open projects of mine that keep me up at night are below. There's probably more but these come to mind. Somewhere between working the day job, spending time with my family, and making sure I take care of my health and stress levels through excercise: I will make incremental progress.

1. rebuild IBM Model-M Keyboard after kids spilled water on it (open for 2 years now)

2. complete floating shelves in office (open since March - 95% done - slowwww)

3. build temperature sensor network for my house using ESPHome firmware and Home Assistant. Hardware purchased.

4. repurpose old 3d printer servo motors to automate etch-a-sketch (popular project out there). Software part started.

5. split-flap display: make my own. research on CAD models for 3d-printing completed.

Its not overwhelming clear that finishing is an important piece of a side project. Real work at your job is the place where you can prioritize finishing over other outcomes. By not forcing yourself to finish everything in your side projects you open yourself up to greater levels of exploration and learning which is, after all, the point of side projects to begin with.

My current project is a monster. It’s been running hot and cold for at least several years.

Progress is being made, but now and again I face something particularly difficult, I can get waylaid.

Right now I’m in such an impasse. I was moving along, making some good progress, when I turned a corner and went “oh no”. It’s like hiking a trail and you turn a sharp curve and see it gets really steep. “Ugh”

That whooshing sound is the wind falling out of the sails. Right now I’m in a dead calm.

But that’s ok. I have several, large subassemblies at the 85% mark, and others to work on that will slot into this thing.

I have “shipped” one project. Docs, releases, installers, whole thing. Getting that polished was 2-3 months. (Calendar, these are not full time projects.)

Finishing was important because I am not a finisher. I like to say I’m a framer and drywaller. Someone else needs to come in to mud, sand, paint, and trim. I’ve never worked well at that level of detail. It’s another reason I’m not very good with GUIs. Lots of detail. But, these are GUI projects.

But also, I shipped my “1.0”. I do not consider it an MVP. No, it’s done. I have no real plans to go back to it.

If I were to ship an MVP, that’s just an excuse (for me) to not finish it. And I did not want to leave a lingering carcass. My drive is already filled with those.

So I continue to push my boulder in silence. Maybe I can release this thing next year. Waiting for the breeze to come up again.

I completely agree, finishing matters, and this reminds of a joke where I said to

I think it's all about prioritization. There are ideas that come to mind while implementing something you have in mind that are unnecessary right now by some definition (could be infamously performance- or perhaps convenience-related). If you have a list of all the subcomponents you need (or rather, want to have) I think it's healthy to first sit down and triage everything into some priority buckets and only zoom in on the absolute base functionality first for you to be able to move on to the next step on top of it for it to be able to ship. Note that this step is completely different in nature than what we have already one. After that you can go back and do the next bucket and so on and so forth.

Not going to lie, I read the title as the Art of Fishing... and spent the entire article waiting for the finale where some how this was an analogy with fishing...

came for the fish, stayed for the all-too-familiar feeling of incomplete projects.

I use the reward system with a slight twist:

I'm not allowed to start a new project until I complete my current one.

Since I have a huge backlog of ideas, my "reward" for finishing a project is that I get to work on the next most exciting idea. Yay!

This forces me to keep the scopes small.

I'm allowed to rescope my current project to something smaller/imperfect after I've started (for example if I discover that my initial vision is going to take too long), but I still have to finish it before I'm allowed to start the next one.

I used to have the same issue then started running and changed my approach. Now:

1.) When you run, you’re only finished training when your body gives out, you die or give up the sport. In software, a product is never really finished; a version is. Therefore if I forget something or mess something up, I already know what tasks to work on for the next version. Forgetting something is bad but it makes planning easier. If finality is scary, turn it into a yield sign.

2.) If you want to run well at a distance, you have to specialize in that distance. If you train for Leadville and the 100m dash simultaneously, you won’t perform as well at either. In software, I work on one version of one product at a time. If I have to choose which one to work on when I sit down, I have already failed.

3.) I’m a human so for me, running is all about pace. Anyone can complete any race if they find and keep their pace. Software is the same. So find your pace and learn how to keep it. When I’m trying to find my pace for a race, I run that pace six days a week regardless of my distance - on shorter days, I’ll add in gliders at the end so I get the workout. With software, I have to keep the same kind of consistency or it takes me too long to get back where I was to ever finish anything.

4.) If you want to run fast so you can see the stars backs for a few moments, you have to treat every single training session just like the race. If you want to run fast enough to be one of the stars, it has to be your whole life. With software, everything even silly side projects gets the same name - product - and I follow the same methods. Practice is always good but deliberate, competitive practice is better.

I like to ship stuff. I actually get pleasure from releasing stuff into the wild.

Shipping, is, by definition, "finishing." Lots of boring stuff involved.

Most of my R&D and learning is geared towards shipping projects.

I will "let stuff go," if I find I'm in a rabbithole. Learning when to do this, is important. I just let go of some ML stuff for Apple systems, mainly because I can't really apply it [yet] to the types of apps that I'll ship. It wasn't a total loss, though, because I learned that I really need to use Intents for what I want.

So, right now, I am learning Intents development for Apple systems. It's a pain, because the documentation is really haphazard, but I'm muddling through.

I'll start by adding them to a released app that I tend to use as my "pointman" for new stuff, then, I'll add it to some of my other shipping apps. While I'm doing this, I'll become "conversational" in the tech. That's how I always learn this stuff. Maybe I'll write something up on it (like I did for Universal Links[0]).

[0] https://littlegreenviper.com/series/universal-links/

I have this with learning piano pieces. The most interesting learning and development occur in the first stages of learning a piece. But "finishing" it takes a lot more time and can feel like drudgery - but if I don't push through it on at least some of my pieces then I'll never have anything that's really performable.

I have spent the last few weeks getting totally detailed to the point of losing all focus. For me it has been missing functionality in a framework. Apparently, they never anticipated .NET MAUI using SVG images for icons. They convert the SVG to PNG for you automatically, and make it easy to display but I need to alter the stroke color with theme bindings. Easy and convenient in WPF. Shit show in MAUI.

My biggest impediments to finishing in recent years has been setting too big of a scope for "done" and running into hundreds of yaks that need shaving off from some buggy-ass framework or library (literally all of them). Rarely anything is as advertised and it has major impacts on delivery.

The only frameworks that let me get shit done without six ways of hell was WPF and Swing.

There's a really important distinction that should be made between personal "fun" projects and professional "work" projects.

Yes, you should definitely learn what's involved in finishing a work project and how difficult this actually is. The old I'm 80% through and I just need to finish off the last 80% is something that can only be learned by experience.

But honestly, why ruin your fun projects by turning them into work.

    In professional settings, being known as someone who starts things but doesn’t finish them can be detrimental to your career.

I would also take issue with this. It may hurt your career, but it may also be your career. Being someone who can break new ground and start a project from nothing can be incredibly valuable and is often a very different skill from putting something into production.

The description and feelings resonate, but I've realized a huge drag on my personal projects is the accumulated accidental* complexity due to tools and dependencies. If it's been a few weeks since you were last able to code, then not only have you lost a lot of context in your working memory, but your tools and dependencies will have marched on, and what seems like a harmless update will often result in hours untangling a bug with Someone Else's Code.

Fixing Someone Else's Code is not the point of such endeavors. Reduce tooling and dependency complexity to the bare minimum, even if it means adopting a bit of NIH mindset.

*as used by Fred Brooks in _No Silver Bullet_, https://www.cgl.ucsf.edu/Outreach/pc204/NoSilverBullet.html

Interestingly, I’ve learned more from learning to let go from this idea of finishing a useless idea. A “project” doesn’t inherently mean “useful”. Sometimes I’m just dillying around on something useless and eventually I recognize it as such and cancel it.

It’s better to just not do things than to do something unnecessary really well.

Finishing is a construct, an escape. No project is ever done. There are always improvements to be made, bugs to be squashed. "Finished" is just a label we put on a place on the timeline, a point after which someone is morally allowed to jump ship.

Example: I'm in the middle of moving jobs (military to other military). I was given a couple weeks to train my replacement, an impossible task. My boss just asked me if I had "finished" training him. Um ... well .. I am leaving. So whatever training we are doing is certainly over. That is what "finished" actually is. Is the job finished? Certainly not. But my time as a contributor has come to an end and so I am finished with the task and am jumping ship.

I think the issue, in the author's case, is that they don't have any projects they truly and completely believe in. The part where they sit down and browse through their archive of unfinished projects is telling. To really get one across the finish line you have to wake up thinking about it and have the completed vision of it burning a hole in your brain and that's what keeps you pushing through all the yak shaving and CSS refactors day after day.

Which is to say, I believe the "productivity porn" angle - setting up certain processes/systems - is a red herring. Inspiration is the driving force.

there's probably some cost to having a bunch of unfinished projects occupy my mental bandwidth but I think there are some benefits:

  - having unfinished projects gives my mind a comfortable place to go think itself out when I'm tired and need to sleep.
  - each project doubles as a kind of lookout tower providing some perspective on other related projects or relevant technologies, and this keeps me interested in paying attention to new developments in non-superficial ways.
  - every once in while a spark of motivation will appear for a project I haven't touched in years and it'll be something I recently learned backpropagating constructively, tightening the whole mess up a bit and helping me retain it all.

I very strongly relate to this, it's been close to 3 months, since I have started working on a blog built on Quarto, and all I have so far is a elaborate design and a half complete blog on an LLM tool I had built.

But like the comments say, I had way too much fun on the journey of a side project, just doing other things like configuring the website and playing around with the design elements like font and how the overall website looks (I'm a data scientist and never usually get to play with design as much as I want to at work). And recently, with claude's help built some cool react elements to push my story further.

Hopefully after this, I ship at least one blog and iterate on the design elements.

Now add neurodivergent executive function disorders -- easily accessible fun things being available prevents bigger picture fun things from starting. I've spent years trying to address this, but haven't found anything that consistently works.

Drives me up the wall.

If it's not a project that others rely on, you should feel free to do it anytime or spawn new projects. To finish it or not doesn't matter much, enjoy the journey and learn from the experience is a value in itself.

There're different currencies driving software development. Your work project is driven by money. Your side project is driven by passion. To push your personal projects to completion, nurture your passion, whatever your passion is.

Projects I've finished are usually always projects I want more than I want to make them.

For example, I made a notes web app that syncs to S3, has full text search, has a "daily note" button that auto creates a note for the day, etc. This app was not the most fun and exciting app to make, but I made it anyway because I wanted it to exist.

There comes a point in projects where you're in the middle of it and you want to switch and do something else. But if you constantly find the desire for the thing you're making, invariably you'll finish. And it gets more fun after the trough of boredom.

I think every project passes a threshold after which the time invested will only be considered worthwhile if you ship it.

Before this threshold, you're learning new technologies, trying new techniques, and generally developing skills that could be applicable elsewhere. After this threshold, you're becoming an expert in the project itself, which will all be for naught if you don't finish it.

So my advice would be give up on projects that are near that threshold, and only continue beyond if you intend to finish it.

It's easier to finish if your goal is to make money - then you are forced to make your customers happy and finish things.

If the rewards are nebulous, then so will the motivation to complete anything.

I decided a while ago that my personal project must either be released as Open Source or commercial software. That keeps me honest, because releasing software as Open Sources exposes it to others so I try to make those projects as good as I can make them and releasing commercial software incentivises me to make it cost me less in support cost. That approach has helped me cull the number of unfinished projects.

I really like the orientation of that chart. Next time I put a long time series chart in a document I'm doing time on the Y axis starting from the top.

Always have to keep project scope at bay. We dont have infinite time nor energy, so there's only so much we can do at any one time.

Make the goal at the start and ruthlessly discard (note somewhere else) any additional ideas. I find myself giving up projects after coming up with brilliant extensions to the project. When I look at it, it's way too big and immediately demotivating.

i'm reminded by this chapter of the tao te ching:

When people see some things as beautiful,

other things become ugly.

When people see some things as good,

other things become bad.

Being and non-being create each other.

Difficult and easy support each other.

Long and short define each other.

High and low depend on each other.

Before and after follow each other.

Therefore the Master

acts without doing anything

and teaches without saying anything.

Things arise and she lets them come;

things disappear and she lets them go.

She has but doesn't possess,

acts but doesn't expect.

When her work is done, she forgets it.

That is why it lasts forever.

The problem is, writing software is REALLY time consuming.

It takes months of full time effort to built something that resembles a working application.

Finishing things (esp. personal projects) feels really good. Leaving them unfinished starts to feel really bothersome. I think the author describes a lot of this really eloquently (while I would also note the irony of writing a meta blog post about this topic during the time when you could have been finishing something).

I have 3 categories of projects:

1. Bigger than I thought 2. Dumber than I thought 3. Too small to really be proud of

My favorite blog post on tips for finishing is this classic by Derek Yu (of Spelunky fame): https://makegames.tumblr.com/post/1136623767/finishing-a-gam....

I'm surprised how software can be a real fight with no end in sight, and then boom, it's suddenly "done". By "done" I guess I mean "useful" as it's never done done.

Somehow, I feel like if a project hasn't become incredibly boring to work on, then it's not even close to finished.

The hardest part is finishing a project pre-revenue. There's just little motivation to do it because, at that point, it's too boring to be about the 'journey' anymore; it becomes all about money... Yet you don't know if the project will be able to generate revenue so it's about 'hypothetical money'. As someone who has a huge number of failed projects under their belt, for me it feels like working for 'magic unicorn money'. I rely 100% on the enthusiasm/delusion of my non-technical co-founder to keep me going. In my mind, it's not going to make it... Though I like the fact that my current project is in a niche that I would never have chosen on my own because it's so damn boring (it's in HR search/recruitment sector *vomits*). I was literally optimizing for boringness.

I wish I could come up with one of these startups which can be monetized straight away, no free tier, no complex sales funnel but I think these opportunities are very limited and highly competitive.

From Drake’s Prayer: “…grant us also to know that it is not the beginning, but the continuing of the same unto the end, until it be thoroughly finished, which yieldeth the true glory”

the keyword here is at the end of the article: alarming amount of coffee. There is something neurochemical in highly creative people that needs to be counterbalanced artificially.

instead of finishing my side project, i am reading this post

Congrats to the author for finishing their article!

Frontend work is demeaning endless drudgery. My personal trick is not to bother with styling and call it “homemade, organic”.

The trick is to have a money so that when it becomes boring, you can just set others to finish it... Lol..if only

Cheers to the author for finishing this brilliant essay even if he can't finish his software projects!

This was a great read. I think the "define finished" at the beginning to be useful advice for me.

When the cost of making a change gets close to zero, it's easy to keep fiddling endlessly...

Lol, I'm not the only one who struggled to finish the article even! God, do distracted.

I have a feeling that the author procrastinated on their project by writing this blog

> 1. Define “Done” from the Start

Impossible for almost any non-trivial project.

> Define “Done” from the Start

This has helped me tremendously. Great article.

I honestly couldn't care less about finishing my personal projects.

It's more about moving forward, and dropping projects that aren't interesting anymore.

Love the illustrations, really great usage of excalidraw!

Somebody should send it to Neal Stephenson

Honestly, it took me about 10-11 hours to finish this article just because I wanted to understand "The Art of Finishing", and I totally agreed with what the author was trying to communicate.

> a hydra of new challenges

Well put.

Great read ! May be this js why #buildinpublic helps many creators

Just what i needed to read today, thanks.

Seen !

"Art is never finished, only abandoned." (Leonardo Da Vinci)

1. Clearly identify why your are doing something.

2. Is it really a benefit to _both_ yourself and _society_ . Or are you solving someones issues for a false sense of accomplishment, and silly wages. Note, I do realize the irony of this post, but I find it entertaining so it still meets the criteria.

3. Summarize your time-bounded project goal in one sentence.

Example: “I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth." (John F. Kennedy)

4. Draft the probabilistic path forwards, by adding the finish line first.

https://en.wikipedia.org/wiki/Program_Evaluation_and_Review_...

5. Identify the key deliverables necessary to meet an MVP in your TRL. This narrows the scope of the project to mitigate feature creep etc.

https://en.wikipedia.org/wiki/Technology_readiness_level

6. Are there people with the right skills and motivation to finish each stage of the project? Note, statistically if you are 93% sure you are only really 60% certain on average.

7. Justify the liability of the budget is consistent with personal and corporate budgets. Solving the worlds problems for free may sound noble, but a half-baked attempt is usually foolish, hapless, or destructive to yourself and others. i.e. if the only motive is to make something cheaper, than you will likely end up worse off for the effort.

8. Landing the belly flop... Can deliverables be re-used in other projects? Does the project still meet its goals in commercial, scientific, and or entertainment markets.

9. Start testing the hardest key deliverables first with toy sub-projects. If these don't succeed, than don't bother tooling up with funding for the rest of the project.

10. toy sub-projects are sometimes regression tests, small programs, or key problems with unknown solutions. Expect these to fail or be repurposed 52% of the time, but if they don't work for the intended role than the path is non-viable.

Finally, I must observe an interesting phenomena when the probability of completing a key deliverable is below 50%, number more the 3 nodes in a PERT serial traversal, and do not have redundant options. Irrespective of a project complexity, the team will fail to reach its goal regardless of the talent pool, time window, and budget.

Best of luck, =3

My guy discovered what Agile really means

The natural tendency is to tackle the hardest parts first, because it's intuitive that the low hanging fruit will be easy and therefore bring more satisfaction. However, I found that tackling what one knows first -- the low hanging fruit -- injects new energy and satisfaction and is critical to mustering the willpower to tackle the hard parts. I found out that solving the low hanging fruit often ends up offering insight into solving the hard problems, and thus finishing a project.