Thoughts on Technical Project Management and Its Intersection with Blockchain's Disruptive Potential

Tag Archives for " successful projects "

Here’s Why Planning is the Most Important Project Phase

I organize projects into four high-level phases. Doing this provides a simple and consistent frame of reference for everyone involved in the project. The first phase, Planning/Initiation, is the most important project phase.

The Planning/Initiation phase sets the foundation for the other phases. It’s often overlooked in the excitement and urgency inherent to launching a new project.

Here are the major activities in the Planning/Initiation phase -

-Develop client requirements

A project's dead in the water without these.​

-Present/align/iterate/confirm client requirements and expectations

This is a critical step. The excitement and urgency of getting a project moving causes this step to get skipped a lot.

-​Determine/assign required resources

You need to know who’s doing what.

-​Develop plan

This will be the roadmap for the project. Adjustments will be necessary to keep the project synchronized over its lifecycle. The best plans need to be flexible, since it’s impossible know what’s going to happen in “real life”, when a project starts.

-​Confirm plan with client

Again, this is another critical step that’s often overlooked. Do what it takes to get your client’s attention long enough to confirm the plan with them.

-Agree to a process to introduce and implement changes to the original plan, as required​

The best plans need to be flexible, since it’s impossible know what’s going to happen in “real life”, when a project starts. This step introduces the possibility of change early and reduces resistance to change later in the project.

Don’t skip the Planning/Initiation stage of your project. Don’t let your client convince you to, either.

The project will have a much greater chance at success when this phase happens. You and your stakeholders will be happier as a result.

P.S. Planning/Initiation is the first of my four dead simple project phases. Read this post to learn about all four phases.

[Updated — The ENS Relaunch was a Success!] How a Project Manager Can Help the Ethereum Name Service Launch Succeed This Time

Published March 23, 2017 in Technical Project Management - 1 Comment
Timeline from Nick Johnson’s Postmortem

How a Project Manager Can Help the ENS Launch Succeed This Time

The first attempt to Launch the Ethereum Name Service (ENS) failed. Here’s how a project manager can make the next try successful.

The Ethernet Name Service (ENS) launched for a short time on March 14, 2017. The ENS community discovered two major security flaws shortly after launch. The team and community behind ENS decided to roll back the launch and try again.

Updated — I joined Nick Johnson and Alex Van de Sande on the ENS team shortly after the first launch attempt, to help with the relaunch. The relaunch was a success!

You can find the latest ENS news here.

I give the team a lot of credit for — 

  • Trying to launch the service in the first place
  • Getting the project to launch
  • Having the awareness to acknowledge problems and address them
  • Making the hard decision to pull back and try again
  • Their transparency in acknowledging what didn’t work and why
  • Their commitment to getting it right, by trying again

You can read about how things unfolded and security flaw details in -

Like Nick’s approach, I hope this post identifies places where a blockchain project manager can help projects like this succeed. It’s not intended to criticize, point fingers or place blame, AT ALL!

It’s also my offer to donate some of my time to provide project management oversight for the project!

(Nick Johnson, if you read this, let me know if you’d like to take me up on the offer.)

How a Blockchain Project Manager Help the ENS Launch Succeed this Time

I’ve written a post about the value project managers can contribute to blockchain projects. This post is a case study to that earlier thesis about the need for blockchain project managers to manage blockchain projects.

This rest of this post -

1 — Lists the causes and issues mentioned by Johnson and Maurelian

Nick Johnson and Maurelian identified many of the same causes and issues in their post-mortems. Each also identified other issues. This post focuses on the issues mentioned by both of them, for the sake of brevity.

2 — Describes how a blockchain project manager could have helped prevent each cause and issue.

Spoiler Alert — The Takeaway

Technical people develop technical solutions to difficult problems. That’s what they do. That’s what they want to do.

What’s missing is someone keeping an eye on the big picture to -

  • Identify issues before they become problems
  • Coordinate resources, making sure there are enough and guiding them to where they can be most effective
  • Gracefully slow down the project, only long enough to help everyone pick up their heads, adjust the end goal as needed and stay synchronized toward the agreed-to end goal
  • Do the work developers don’t want to do, e.g. document the project, coordinate audits, confirm thoroughness of plans, develop contingency plans etc

A blockchain project manager keeps an eye on the big picture. Keep reading for more detail.

(You can also contact me to discuss how I can make your blockchain project a success.)

Causes and Issues

Issue 1 — Incomplete Test Coverage

Johnson — Although the registrar had a suite of unit tests, this testing was not comprehensive. The unit tests were written after the contract by a different author. No concerted effort was made to ensure that all code paths or use cases were thoroughly covered.

Maurelian — Both of the issues uncovered could have been caught with tests to verify proper behaviour of the registrar. The behaviours which the issues enabled were not edge cases, but rather specifically prohibited…only 13…tests were on the Registrar contract, which has at least as many methods and many more requirements than that.

A blockchain project manager could(’ve) help(ed) by making sure the unit tests covered all code paths or use-cases by -

  • Developing a checklist of code paths and use-cases
  • Coordinating resources to execute the unit tests
  • Consolidating the results
  • Coordinate issue resolution

Issue 2 — No Formal and Independent Audit

Johnson — No independent, comprehensive audit was done.

Maurelian — There was no formal audit. There is unfortunately no single document summarizing what review was done, and what was found.

A blockchain project manager could(’ve) help(ed) by — 

  • Running the process to select an independent third party to conduct a formal audit
  • Acting as the liaison between the development and audit teams
  • Developing the review summary document

Issue 3 — Insufficient Code Review

Johnson -The changes to the contract that introduced the bugs were subject to review in a Pull Request, but the review did not catch the bugs. In future, more care is needed when reviewing changes to critical code to ensure reversions aren’t accidentally introduced.

Maurelian — (Referred to this issue as thrashing.) It’s nearly impossible to audit an evolving code base…Many changes were made between the Ropsten launch, and the live net launch…I actually looked at the commit that introduced these issues, but it’s a large contract…the effort required to…understand the full implications of the change felt onerous.

A blockchain project manager could(’ve) help(ed) by maintaining documentation that would make it -

  • Faster and easier to identify changes between commits.

Which would -

  • Make change implications feel less onerous to developers, who are already time-limited, allowing them to be more comfortable conducting code reviews.

A blockchain project manager could(’ve) also help(ed) coordinate more resources to conduct code reviews.

Issue 4 — No Official Bug Bounty

Johnson — A good bug bounty has…real value up for grabs…this is hard to do on a test net, where the tokens have no value, and stuff is expected not to work…WeiFund’s live net bug bounty, which held over 200,000 USD worth of real value in deployed contract, is a good counter-example. Blockchains present an interesting opportunity for a “natural bug bounty”, we as contract developers should be taking advantage of this.

Maurelian — No clear indication was provided to the community as to whether ENS was covered by the Ethereum Foundation’s bug bounty process. Had it been announced that ENS was covered, more attention would likely have been directed towards the code at an earlier stage in the process, resulting in the bugs being found at a stage where they could be easily remedied without affecting the launch.

A blockchain project manager could’ve helped by coordinating — 

  • Development of a Wei-Fund-like bug-bounty.
  • Alternative motivational programs, to encourage others to take part in the bug-bounty process.
  • Communicating a bug-bounty marketing plan.

Issue 5 — Incident response planning

(This one was only mentioned by Maurelian. I thought it was worth a mention, since a blockchain project manager could play a very valuable role here.)

Maurelian — …but bugs were always a possibility, so the need to delay should always be considered in advance. A common approach is to have a play book, basically, “if X happens, we will do Y”. I think that the reaction so far has been suitably transparent and proactive, but would have been better organized if the decisions had been made beforehand.

A blockchain project manager could(’ve) help(ed) by — 

  • Developing the play book.
  • Managing responses during implementation, according to the agreed-to playbook guidelines.

Here’s the Takeaway — Again!

I figured a repeat of the take away’s in order, if you read this entire post. And thanks for reading if you did!

Technical people develop technical solutions to difficult problems. That’s what they do. That’s what they want to do.

What’s missing is someone keeping an eye on the big picture to -

  • Identify issues before they become problems
  • Coordinate resources, making sure there are enough and guiding them to where they can be most effective
  • Gracefully slow down the project, only long enough to help everyone pick up their heads, adjust the end goal as needed and stay synchronized toward the agreed-to end goal
  • Do the work developers don’t want to do, e.g. document the project, coordinate audits, confirm thoroughness of plans, develop contingency plans etc

A blockchain project manager keeps an eye on the big picture.

P.S. — Working on a blockchain project? Contact me to discuss how I can help make your blockchain project a success.

Here’s Why Your Project Needs a Blockchain Project Manager

Published March 13, 2017 in Technical Project Management - 1 Comment
blockchain project manager

You're a brilliant blockchain developer. You're excited about the potential blockchain offers your clients. Your clients are excited about the potential blockchain offers their businesses. They've hired you to help them realize that potential.  Here's why you need a blockchain project manager to make that happen.

You're both excited. You sign the contract. You and your team puts your collective head down. You do what you do well. You start coding. That's what the client's paid you to do, right?

You work through nights to hit deadlines. You tell your client's everything's looking good.You start to feel a disconnect between you and your client. You start to get frustrated. They start to get frustrated.

The initial excitement you both shared turns into frustration. You hesitate to contact them, since the conversations are getting tense. Instead, you put your head down and code more. That's going to fix the problem, you think.

What you're building digresses from what the the client wants. The frustrations builds. The tension does too.Timelines get stretched. Budgets get stressed. You keep working and your profit margin keeps shrinking. The client's budget keeps growing. They start wondering if they hired the right person. They start wondering if this whole blockchain thing is only smoke and mirrors.

Why is this happening?

You Don't Have a Blockchain Project Manager​

You don't have anyone managing the project or client expectations. You're doing what you're good at. You're coding away.

The trouble is, it's hard to see the big picture at the same time. It's not your fault. It's not where you're hired to focus. Your focus is solving difficult problems with creative technology solutions. That's what you do well. That's why clients hire you.

This is a major reason what you build diverges from what the client needs. Another one is that clients, especially with an emerging technology like blockchain, need you to tell them what they need. Some clients need you to tell them a lot, others less. But they all need at least a little guidance.

This means aligning expectations is a critical function. It needs to happen at the beginning of a project, when everything's looking rosy.

Expectations needs to stay aligned during the project. Sometimes this means the conversations become a little uncomfortable. Having the uncomfortable conversations throughout makes the really uncomfortable conversations less likely to be necessary.

The comfortable thing to do is write more code. The uncomfortable thing is to have the uncomfortable conversation. Doing the comfortable thing in this case causes expectations to diverge even more.

This is why your blockchain project needs a project manager. This person will manage the alignment process. They'll keep your work aligned with client expectations. This will let you focus on what you do well, while ensuring the client's expectations get met.

A Blockchain Project Manager​ Makes Everyone Happy

Having a dedicated project manager in this role reduces frustration. This person will manage frustration skillfully when it does arise, since it will still arise here and there. A blockchain project manager will help make your project successful.

Everyone will be happier as a result. The client will realize the value of blockchain. You'll enjoy the satisfaction that delivering a creative solution for a happy client provides.

This is why your blockchain project needs a blockchain project manger.

Convinced?

Are you convinced a blockchain project manager can make your project successful? I'd be happy to manage your blockchain project. I'd also be glad to get your existing blockchain project back on track, if it's already gone awry.

Either way, contact me and let's talk!​

Not Convinced Yet?

Still want to go it alone, without a blockchain project manager?

Please at least read how I manage critical client expectations and try and do the same for your project. If you're able to do this, while still doing what you do best, you'll save yourself trouble down the road.

(Photo credit Bogden Dada via Unsplash.)

This is the Template I Use to Align Critical Client Expectations

Published February 16, 2017 in Freelancing - 0 Comments
align critical client expectations

Aligning client expectations at the beginning of a project is the key to their happiness and yours. Availability and communication expectations are two of the most important to align.

It's important for clients to know when and how they can reach you. It's also important for them to know when they can't.

And it's OK that they can't sometimes. I agree with Jason Fried, CEO of 37Signals, that sometimes work can wait

If you’ve used a modern chat, collaboration, or messaging app, you’ve probably noticed that there’s a growing expectation of being available all the time. Someone at work hits you up on a Saturday, you get the notification, and what are you supposed to do? You could ignore them, but what’s the expectation? The expectation is “if you’re reachable, you should reply.” And if you don’t reply, you’ll likely notice another message from the same tool or a tool switch to try to reach you another way. And then the pressure really mounts to reply. On a Saturday. Or at 9pm on a Wednesday. Or some other time when it’s life time, not work time.

…We believe Work Can Wait is an important notion. 9pm on Friday night is not work time. 6am on Wednesday morning is not work time. It may be for you, but it’s not for me. And I don’t want it to be work time for my employees either.

Jason Fried 
CEO, 37Signals

(My gratitude to Ian Patrick Hines for pulling out this version of Jason's quote in his post about fostering a healthy work culture in a client services business.)

Here's the template I use to set align my clients' expectations. I send a version of it to each new client I work with, at the start of our first project -

I find it helpful to set availability and communication expectations with new clients and partners. Here are a few notes about my availability and communication style.

I've learned these guidelines enable -

-You to do your work with minimal disruption and distraction, while not having to worry about what you hired me to do

-Me to perform at my best for clients

-A successful collaboration and project delivery

General -

A big reason I freelance is to maintain a healthy work/life balance. I have a strong appreciation for balancing hard work and well-being. This balance enables me to bring sustainable high performance to the work I do.

You can read more about this approach on my blog. 

Availability -

I'm generally available between 9A-5P US ET. I can be available outside of those hours if needed. The more advance notice given, the more likely I can be available outside that window.

Communication -

I believe in the power of asynchronous communication.

I've also learned it's important to have uninterrupted blocks of work time.

This is why I'm not tied to email or chat/IM at all times. I check email often enough to not miss key messages. I'm on chat/IM when we've scheduled a time to talk, etc.

It's also why I use Asana to manage projects. Using Asana helps us streamline our communications and keep our Inboxes clean! Hopefully most project communication happens in and through Asana.

If you need to get in touch with me right away, please text or call on [my mobile #]. I'll respond as soon as I'm able to.

(Photo credit Galen Crout via Unsplash.)

Here’s What the Best Project Managers Do and Don’t Do

Published January 24, 2017 in Technical Project Management - 0 Comments
The Best Project Managers Keep a Project Running Smoothly

The best project managers keep a project running smoothly. We also stay out of the way. That means doing some things and not doing others. Here are the do's and don'ts of the best project managers.

Do set the path to a successful outcome. Do keep the path clear and stay out of the way. Don't block the path.

Do set the path to a successful outcome by developing, updating and communicating the path. Do keep the path clear by removing roadblocks. Do give your team what they need to make progress down the path, toward the successful outcome.

Do ask questions when they benefit the project. Do ask the hard questions when necessary.

Don't block the path. Don't get in the way. Don't impede progress. Don't establish process related roadblocks on the path. Don't stop people smarter than you from doing what they need to do. Don't be afraid to admit when you don't know something.

Don't ask unnecessary questions for your own personal benefit. Don't shy away from asking the hard questions when necessary.

Do set your team up for success. Do give credit to team members where and when credit is due. Don't take undue credit when the team succeeds.

Do take responsibility when things don't go well. Don't blame the team when a project goes off-track.

Do celebrate small wins along the way. Do use the small wins to build momentum toward the bigger goal. Do try and have some fun as you proceed down the path toward a successful outcome 🙂

A project manager who follows these do's and don'ts will keep a project running smoothly. A project manager who doesn't follow them will only cause problems and get in the way.

Contact me to work with a project manager who follows these do's and don'ts. I'll keep your project running smoothly.​

Here are Simple and Easy Project and Product Manager Definitions

Published June 17, 2016 in Uncategorized - 0 Comments

​Comparing Project to Product Manager Roles is Like Comparing Apples to Apples

I've managed projects and products. I don't see a big difference between the two roles, if you view a product as a project. Then again, I believe project management should keep things simple.

I believe these two roles and their definitions get too complicated. Viewing a product as a project keeps things simple. Project management should aim to keep things simple. That's why I favor a simple definitions and simple approaches.

Let's start with some simple definitions.

What's a Project?

A project is a set of defined tasks executed to achieve a desired outcome.

What's Project Management?

Project management is defining those tasks, leading their execution and delivering the desired outcome.

That's it.

Yes, sh*t hits the fan!

Yes, in practice, sh*t hits the fan along the way.

I find setting a simple starting point sets a clear intention for a project. A a clear intention grounds the project. Keeping the project grounded helps focus it.

Keeping a project focused helps -

-Limit the amount of sh*t that hits the fan

-Bring the project back on track once the sh*t hits the fan

Everything's a Project

Viewing everything from a project perspective keeps things simple. If you view everything from a project perspective then -

-A product is a type of project

-A program is a collection projects or

-A program is a collection of products, since a product is a project

What's the Difference Between a Project and Product Manager?

So along these lines -

A project manager is a project manager. A project manager may manage a project, program or product.

A product manager is project manager. A product manager manages a product as their project.

That's my simple view of things.

Photo credit Raquel Martinez via Unsplash

Here Are My Dead Simple Project Phases

dead simple project phases

Only four dead simple project phases? What are we going to do with all these people then?

Project management should be simple. There's no reason for project management to become a complex monster that feeds on precious project resources. Project management should maximize the effectiveness of resources. It shouldn't consume them.

Here are four dead simple project phases I use to manage projects. I break projects into these four high-level phases. Doing this provides a simple and consistent frame of reference for everyone involved in the project.  I've also listed the major activities that happen during each phase.

Project Phase 1 -Planning/Initiation

  • Develop client requirements
  • Present/align/iterate/confirm client requirements and expectations
  • Determine/assign required resources
  • Develop plan
  • Confirm plan with client
  • Agree to a process to introduce and implement changes to the original plan, as required

Project Phase 2 - Execution

  • Track progress to plan
  • Manage and maintain the right resource levels to maintain consistency with the timeline and budget
  • Report on adherence and deviations to plan to internal and client stakeholders
  • Realign plan and expectations as required, identifying any potential reasons for realignment as far in advance as possible
  • Remove roadblocks preventing the team from making progress and hitting their goals
  • Maintain positive team morale and motivation
  • Recognize and celebrate the successes as they happen, not just at the end of the project
  • Try and have some fun along the way 😉

Project Phase 3 - Delivery

  • Baseline product being delivered against requirements
  • Present product to client and collect feedback
  • Address client feedback, balancing requests against original requirements vs. additional work, e.g. scope increase
  • Determine next steps, if any

Phase 4 - Ongoing Support

  • Similar steps to 1-3 above, done on a recurring basis, on a schedule agreed to with the client
  • Additional emphasis on reporting can be helpful during this stage, so clients consistently remember the work that’s being done, not just when they receive an invoice 🙂

You can also learn about my dead simple project management principles in this post.

Here Are My Dead Simple Project Management Principles

Published March 2, 2016 in Technical Project Management - 0 Comments

Trying Hard to Keep It Simple

Project management should be simple. There's no reason for project management to become a complex monster that feeds on precious project resources. Project management should maximize the effectiveness of resources. It shouldn't consume them.

Here are some dead simple project management principles I try and follow. I review them before initiating a project. I also come back to them once a project leaps forward from the starting gate.

I find them to be a grounding and refocusing tool. They help prevent managing a project from becoming bigger than the project itself.

Dead Simple Project Management Principles

Do set the path to a successful outcome. Do keep the path clear and stay out of the way. Don't block the path.

Do set the path to a successful outcome by developing, updating and communicating the path. Do keep the path clear by removing roadblocks. Do give your team what they need to make progress down the path, toward the successful outcome.

Do ask questions when they benefit the project. Do ask the hard questions when necessary.

Don't block the path. Don't get in the way. Don't impede progress. Don't establish process related roadblocks on the path.

Don't stop people smarter than you from doing what they need to do. Don't be afraid to admit when you don't know something.

Don't ask unnecessary questions for your own personal benefit. Don't shy away from asking the hard questions when necessary.

Do set your team up for success. Do give credit to team members where and when credit is due. Don't take undue credit when the team succeeds.

Do take responsibility when things don't go well. Don't blame the team when a project goes off-track.

Do celebrate small wins along the way. Do use the small wins to build momentum toward the bigger goal.

Do try and have some fun as you proceed down the path toward a successful outcome 🙂

This post is based on an answer I wrote on Quora to the question "What are the top do's and don'ts that a new project manager should remember?"