• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Project Management Framework - proposition

kot

Moderator
Masternode Owner/Operator
Dear Community Members,

I have challenged myself to create a flexible methodology to control our projects. Methodology that synthesizes the classic principles of good Project Management with the innovation of Dash technology.
This methodology is a living framework that will be updated as we continue to develop the project and the way we manage our work.

Sooner or later we will need this type of tools to deliver our projects in a professional and effective way I do not know if we need it today but I am sure we will need it in the future - it is better to be prepared for this future.
Therefore I would like to share with you a first draft of the framework and initiate a discussion with anyone interested in development of the framework.

What is Dash Project Management Framework (Dash PMF)?
  • Dash PMF is a methodology of Dash Project Management for projects funded from the DGBB system.
  • Created based on industry standards: PMI and PRINCE2.
  • Customized based on project management experience gained in differnt industries.
  • Tailored to Dash project needs and expectations of the stakeholders and community.
  • Tool- and methodology-agnostic.
  • Defines what needs to be delivered for the benefit of Dash but not how Vendors should deliver projects (it is up to Vendor to choose proper methodology)
The main presentation is available in this location - PLEASE READ NOTES UNDER THE SLIDES: https://dashpay.atlassian.net/wiki/download/attachments/37355559/00. Dash-Project-Management-Framework.pptx?api=v2

Please let me know what do you think about it and share your feedback - any suggestion is priceless. Let's create together a good method to deliver what we need :).
Thank you
 
Last edited by a moderator:
Hi Kot

The slides content looks great.
For the project workflow slides, between Deployment/go live and Project close, possibly include a "lessons learn't"

Adding Stakeholder communication at different milestones could stop masternode down voting.
On another note, how may projects are currently running and how are they managed?
Are they visible to track by stakeholders? Have you ever used Trello? https://trello.com/
 
Hey kot thank you for posting. I know you say we don't need this now, but for future refence I'm wondering how will you get project owners to work with you on using the framework for their own projects, will this be something that is actually required for budget proposals? What if somebody is not willing to use this, even if it is something that will help them? I'm not really an expert in this area so I don't have many comments or questions. I did see 1 typo/error on slide 5 though. Under the Admin person chat bubble, for some reason the 'n' on configuration is on the line below 'confignuratio' -

Anyways thank you for taking the time to do this if there is any way I can assist you let me know.
 
Kot, I know you are trying to make the Dash budget process into an ISO standardized document based on the QMS that is repeatable, measurable and constantly improving, but I don't see this being beneficial.

Just allow the masternode owners to see and understand proposals directly without a middle layer in between and they can think for themselves how to vote. An outside expert in business, venture captial, finance, publicity, or other areas could be useful as a reviewer. But doing reports are not going to do anything but give people more to read.

I would focus efforts on finding experts in certain areas to review. And frankly anyone that has started a business or been involved with higher level decisions in a company are the only ones I would consider. You could also find examples of successful companies that started from scratch and how they spent their time marketing and building their products. We need to learn together,but not by copying the mistakes of the standards that waste so much time in the corporate world.
 
I think this is a great start
buster, I think we should encourage masternode operators to vote against proposals unless they meet a certain minimum requirement, so that's how to incentivize project owners to comply. Or, we can even have the masternode network vote on whether to establish something like this as a network-approved method of governing DASH projects.

Solarminer, I disagree -- things like this will end up *improving* efficiencies, not creating waste. In my view, DASH really does open the door for decentralized governance, not decentralized anarchy. Waste is when masternode operators do not establish something like this and end up creating divisions within the community by bickering and rehashing the same arguments over and over. This does not have to be a final thing, I think we can work with it and continually improve upon it.

kot I haven't had a chance to really look at this in depth, but from what I can see I think this is a really important initiative. Thanks for doing this :)
 
I think this is a great start
Solarminer, I disagree -- things like this will end up *improving* efficiencies, not creating waste. In my view, DASH really does open the door for decentralized governance, not decentralized anarchy. Waste is when masternode operators do not establish something like this and end up creating divisions within the community by bickering and rehashing the same arguments over and over. This does not have to be a final thing, I think we can work with it and continually improve upon it.
This isn't about anarchy or creating divisions in the community. Those statements are not related to my comments or this discussion.

If you had a company making a widget that needs to be the same every time, ISO and QS standards are important along with detailed reports. Then you have metrics in place to base any changes. And you have a system in place to report failures and mitigation methods. We are not building engine parts that need to be accurate to 1000ths of an inch or assembling parts from different suppliers that need to pass strict quality control standards.

Have you ever done a DFMEA? Any of these reporting processes? It is pretty obvious what the problem is from the start....What if the bus stalls on the railroad tracks with kids inside.....yeah..not good. So figure out a way to make that not happen. Reporting doesn't magically make a product better. But it sure doesn't make building a better product easier if you end up spending 90% of your time with reports or reports of those reports.

Everything we are doing with this budget system is new, uncharted territory, and unique. There isn't going to be anything the same....except maybe doing the website a few times. But even then, the 2nd time will be a different designer with new motives. Each project itself may have it's own reporting structure if it is big enough, but that would only be specific to that project.

If you only had one product to build, would you start with a 100 page statement of work, put your design in CAD, make up 10 prints accurate with GD&T(tolerancing and dimensions), plot it with 3ft wide paper, send it to a prototype shop to build it, and then check that it met your dimensions? No that would be insane. You just build it, test, and modify until it works. We are making prototypes....not mass production.

This is the one case that updates end up being a simple summary of what is going on with the project. Nothing fancy. No colors, no bubbles, no progress numbers. Just a statement in plain English for what is happening. And maybe that is a video or presentation if something is more complicated.

The biggest benefit I see is providing the information and resources helpful to make a masternodes decision easier....Like an expert opinion or showing an example of a similar situation from another experience.
 
This isn't about anarchy or creating divisions in the community. Those statements are not related to my comments or this discussion.

If you had a company making a widget that needs to be the same every time, ISO and QS standards are important along with detailed reports. Then you have metrics in place to base any changes. And you have a system in place to report failures and mitigation methods. We are not building engine parts that need to be accurate to 1000ths of an inch or assembling parts from different suppliers that need to pass strict quality control standards.

Have you ever done a DFMEA? Any of these reporting processes? It is pretty obvious what the problem is from the start....What if the bus stalls on the railroad tracks with kids inside.....yeah..not good. So figure out a way to make that not happen. Reporting doesn't magically make a product better. But it sure doesn't make building a better product easier if you end up spending 90% of your time with reports or reports of those reports.

Everything we are doing with this budget system is new, uncharted territory, and unique. There isn't going to be anything the same....except maybe doing the website a few times. But even then, the 2nd time will be a different designer with new motives. Each project itself may have it's own reporting structure if it is big enough, but that would only be specific to that project.

If you only had one product to build, would you start with a 100 page statement of work, put your design in CAD, make up 10 prints accurate with GD&T(tolerancing and dimensions), plot it with 3ft wide paper, send it to a prototype shop to build it, and then check that it met your dimensions? No that would be insane. You just build it, test, and modify until it works. We are making prototypes....not mass production.

This is the one case that updates end up being a simple summary of what is going on with the project. Nothing fancy. No colors, no bubbles, no progress numbers. Just a statement in plain English for what is happening. And maybe that is a video or presentation if something is more complicated.

The biggest benefit I see is providing the information and resources helpful to make a masternodes decision easier....Like an expert opinion or showing an example of a similar situation from another experience.

I didn't mean to imply that anyone is creating divisions in the community, I am just saying that divisions in the community are bound to happen when there is no established consensus on governance issues. I don't consider these to be prohibitive "regulations", I consider them to be like the by-laws of a board of directors. The procedure for resolving disagreements becomes systematic. Does a project come in that doesn't quite fit but it seems reasonable to still approve the budget? Well, then let's either (1) encourage or find a way to assist the proposal owner to comply with the standard established by the network consensus, or let's (2) amend the network consensus to account for the root issue. If no one can manage to do either of those two things, then there is not much excuse left to fund the project because at that point the network has essentially already agreed that the project proposal is insufficient. It seems to me that leaving everything up to discussions on the forums, and then a vote on the budget proposal, is under-utilizing the framework that is already available to us to use real decentralized governance.

For a project, of course you wouldn't start with a 100 page statement of work. But the procedures that are necessary often depend on the scope of the project, which is why kot attempted to define different protocols for smaller budgets vs. larger budgets. If we need to account for a certain amount of flexibility for how different projects should be doing their reporting,...etc, then that's great, why don't we build that right in? Bottom line, in any organization, the governing body needs to establish certain policies and procedures in order to effectively make decisions and to avoid forces that tear the group apart. The DASH network and budget is only going to get even more complex. Now is the right time to be thinking about this and see what we can do with what is effectively a decentralized board of directors. kot's design, even if you might think is over-doing it, I think is a good start at least to get the conversation moving.
 
Last edited by a moderator:
This is a shortcut to an obnoxious corporate culture plagued with inefficiency and nice colored bubbles that make no sense at all. Even worse, they obscure truth and real data and suck the living life out of anyone having to deal with "reporting" instead of working.
 
I didn't mean to imply that anyone is creating divisions in the community, I am just saying that divisions in the community are bound to happen when there is no established consensus on governance issues.

You can't stop people from disagreeing with each other. Some proposals will not be unanimous. That is part of life. The only metric that matters is how many people vote yes. This is so simple. If a suggestion is made, the proposal owner can listen and resubmit a proposal.

Why complicate a simple vote with the extra effort reading and writing reports?
 
You can't stop people from disagreeing with each other. Some proposals will not be unanimous. That is part of life. The only metric that matters is how many people vote yes. This is so simple. If a suggestion is made, the proposal owner can listen and resubmit a proposal.

Why complicate a simple vote with the extra effort reading and writing reports?

By similar reasoning, if the majority think that it is better to establish a protocol, then the only thing that matters is how many people vote yes :p
I think I already laid out reasons why I would prefer to establish protocols. I'm not saying I agree with kot's proposal. As I already mentioned, I haven't even had time to thoroughly examine it, just to get a brief overview. The final product doesn't even have to look anything like what you are seeing. The point of this is to figure out what the network *can* agree on, regardless of whether it looks anything like what kot has put forward.
 
By similar reasoning, if the majority think that it is better to establish a protocol, then the only thing that matters is how many people vote yes :p
I think I already laid out reasons why I would prefer to establish protocols. I'm not saying I agree with kot's proposal. As I already mentioned, I haven't even had time to thoroughly examine it, just to get a brief overview. The final product doesn't even have to look anything like what you are seeing. The point of this is to figure out what the network *can* agree on, regardless of whether it looks anything like what kot has put forward.

We have a protocol...the masternodes vote yes or no.

If you have questions on what the community will agree on start a discussion or do an option poll before the vote. This is a funding system not some complicated decision matrix via a Scantron bubble test.

If you want to make reports of reports on reports go for it, just forward then to file 13. Just because every company above a certain size does reports so they can meet metrics to review reports of metrics, doesn't mean it is efficient or useful. Watch Office Space or spend an hour at a bank and tell me that is efficient use of everyone's time.
 
We have a protocol...the masternodes vote yes or no.

If you have questions on what the community will agree on start a discussion or do an option poll before the vote. This is a funding system not some complicated decision matrix via a Scantron bubble test.

If you want to make reports of reports on reports go for it, just forward then to file 13. Just because every company above a certain size does reports so they can meet metrics to review reports of metrics, doesn't mean it is efficient or useful. Watch Office Space or spend an hour at a bank and tell me that is efficient use of everyone's time.

Yes, I have questions on what the community will agree on, so we are starting a discussion now. Not just on a project, but on *projects*.

Right now, ultimately the "protocol" is a yes/no vote for each budget proposal. I do not think anyone has proposed to actually change this to include any other logic at this point. But I am referring to "protocol" in a different sense. The Masternodes can, and have already, used the budget system to pass what are essentially "resolutions". A statement of intent or demonstration of a network consensus, which can be about literally anything. These are by their very nature, not binding in the sense that they do not directly affect the voting system with respect to actual projects. However there is no other way to truly find out the majority position of the network on a proposed idea. Actually establishing these will resolve any doubt about what the network thinks are best practices for governing itself.
 
Thank you for your feedback. I am really happy to see different opinions - only this way we could build something useful.
Just to give you more insights:
  1. This is not a solution for reporting. Please read the materials carefully - majority of the outcomes are NOT reports. There is very little reporting there - max. 5-10% of entire efforts and it exists only on PM side. Thus this does not affect the delivery on the vendor side but gives a lot of information for the MN owners. The regular meeting schedule makes vendor sharing an information about the project status. This is presented as a report (the same format for all projects - this is a big advantage in fact) and together with the information from the project plan (milestones, deliverables) we have a clear view on the project status. This report is not for PM, as PM is aware of the status, this gives MN owners an input to vote (and information for the community - I have observed that there is a big need for more information).
  2. Let's assume we have a budget worth 5M USD and 75 active projects consuming the budget. Can you imagine MN owners reading each proposal (in different format, different quality, different information) and making conscious decisions? And then each month reading 75 different updates (in different forms and different places) + new proposals?
  3. Having the same assumption as above, can you imagine how many frauds will we have without any control on the projects (based only on the attractive project proposal description instead)?
  4. We are going to build many tools by different vendors using the system - the framework is to ensure quality and complex delivery (complete product and information about the product). Please remember that after successful delivery vendor is gone. There is no reason to assume that they would deliver anything in advance (for free) after the project closure (when we realize that something is missing). Therefore we need to make sure that product is delivered with a good quality but also that the vendors deliver documentation for users, developers, our admins and good description of the product.
  5. This framework does not force vendors to use any particular method to deliver the product. This is up to the vendors how they work.
  6. People who maintain the products will be changing their roles (some will leave the project, some new will come). What is the most effective and safe way to store the information about the products, maintenance procedures, bug fixes, workarounds etc.? Good documentation. And I know - all of us hate to write documentation and (ironically) all of us need it. Without the good documentation (in any format - it does not have to be the Word document) our products will be useless very quickly.
Please also do not use the word "corporate" (in all forms) as a synonym for something bad and useless. This is not a coincidence that corporations make so much money and are successful - they can hire really brilliant people and thanks to this build really good solutions. It is worth to adopt what is useful for us (even if it looks like a "corporate standard"). Do you think that Linux devs or Apache contributors work without any processes and standards?
We need to be smarter - not resistant :)
 
Last edited by a moderator:
Yes, I have questions on what the community will agree on, so we are starting a discussion now. Not just on a project, but on *projects*.

Right now, ultimately the "protocol" is a yes/no vote for each budget proposal. I do not think anyone has proposed to actually change this to include any other logic at this point. But I am referring to "protocol" in a different sense. The Masternodes can, and have already, used the budget system to pass what are essentially "resolutions". A statement of intent or demonstration of a network consensus, which can be about literally anything. These are by their very nature, not binding in the sense that they do not directly affect the voting system with respect to actual projects. However there is no other way to truly find out the majority position of the network on a proposed idea. Actually establishing these will resolve any doubt about what the network thinks are best practices for governing itself.

Neither of these comments have anything to do with the topic of this thread.
 
Thank you for your feedback. I am really happy to see different opinions - only this way we could build something useful.
Just to give you more insights:
  1. This is not a solution for reporting. Please read the materials carefully - majority of the outcomes are NOT reports. There is very little reporting here - max. 5-10% of entire efforts and it exists only on PM side. Thus this does not affect the delivery on the vendor side but gives a lot of information for the MN owners. The regular meeting schedule makes vendor sharing an information about the project status. This is presented as a report (the same format for all projects - this is a big advantage in fact) and together with the information from the project plan (milestones, deliverables) we have a clear view on the project status. This report is not for PM, as PM is aware of the status, this gives MN owners an input to vote (and information for the community - I have observed that there is a big need for more information).
  2. Let's assume we have a budget worth 5M USD and 75 active projects consuming the budget. Can you imagine MN owners reading each proposal (in different format, different quality, different information) and making conscious decisions? And then each month reading 75 different updates (in different forms and different places) + new proposals?
  3. Having the same assumption as above, can you imagine how many frauds will we have without any control on the projects (based only on the attractive project proposal description instead)?
  4. We are going to build many tools by different vendors using the system - the framework is to ensure quality and complex delivery (complete product and information about the product). Please remember that after successful delivery vendor is gone. There is no reason to assume that they would deliver anything in advance (for free) after the project closure (when we realize that something is missing). Therefore we need to make sure that product is delivered with a good quality but also that the vendors deliver documentation for users, developers, our admins and good description of the product.
  5. This framework does not force vendors to use any particular method to deliver the product. This is up to the vendors how they work.
  6. People who maintain the products will be changing their roles (some will leave the project, some new will come). What is the most effective and safe way to store the information about the products, maintenance procedures, bug fixes, workarounds etc.? Good documentation. And I know - all of us hate to write documentation and (ironically) all of us need it. Without the good documentation (in any format - it does not have to be the Word document) our products will be useless very quickly.
Please also do not use the word "corporate" (in all forms) as a synonym for something bad and useless. This is not a coincidence that corporations make so much money and are successful - they can hire really brilliant people and thanks to this build really good solutions. It is worth to adopt what is useful for us (even if it looks like a "corporate standard"). Do you think that Linux devs or Apache contributors work without any processes and standards?
We need to be smarter - not resistant :)

Kot, I appreciate all the effort you are putting into trying to make this easier for masternodes. But I have been through so many situations with new development projects where you just can't push every project into a checkbox sheet. It is just too difficult to gauge every possible activity. (sure you can probably just do software). But the dash project space is vast in potential products.

Documenting certain activities to ensure easy transition if someone leaves, Perfect, that is a great idea. We already do github and wikis. There are probably other tools that can help. Certainly agree with this concept.(even though I don't like it, I understand the value)

As for the idea of a budget worth 5M, Wow! Let's just think about that for a minute....:smile: That was fun. Ok, each masternode is now worth $700,000 and would bring in about $84,000 per year. I wouldn't mind living off of that and reading proposals for a few days each month. In reality, I would probably subscribe to the BabyG or DrBobLQ consulting service that I am pretty sure one of them will start. I would pay $1000/year to summarize the proposals and project status. Rather than pushing all this into a report format process, I would instead suggest that proposals be done with videos - like a 1-2 minute infomercial.

I would also advise any reporting that claims 5-10% now is going to increase. It is a temptation to get more and more detail. I don't want it to start because this will slow down Dash development. I am not pushing back on this because it will be more work, I am pushing back because I think it will only make things worse. It will force certain projects into some weird metric that isn't achievable or is easily bypassed. Let's just pick software. If Evolution was in a project and it has a milestone of the end of 2016....Now PM says we are changing budget programming and bumping Evolution to 2017. Does it get defunded because it missed a milestone? You can't anticipate why things will happen. The masternodes can logically determine this whether reading a nicely formatted template or a simple summary.

This needs to be a human driven process of deciding which projects get funded. And then for contracts have a higher threshold to defund if there is something wrong. Automating these steps with milestones will only cause problems.

I am all about solutions....So I will leave you with one more. How about providing an easy way to convert proposals between different languages?
 
Great input Solarminer .
I agree with almost all what you wrote. If you think about the framework, I have proposed - it is exactly what you are talking about: non-automatic, human-driven and flexible solution. We just need to create the one that works for majority of our projects (there is no way to build a perfect solution for everything, but majority is fine) and then change it according to our needs. What I proposed is not written in stone - it is just a proposal to discuss and change if necessary (and then adopt or not).
Having a template for something does not mean that everything is fixed and automatic... In constantly changing environment (like ours) we need a person like PM/consultant/whoever who takes care of the delivery and deals with changing circumstances (for both Dash and vendors) + a flexible process for delivery.

EDIT: Personally, I would avoid ideas like infomercials - they would consume MUCH more time than simple document. If we go this direction, vendors will spend a lot of time (and money) creating attractive, good-looking videos, instead of giving critical project information in a simple form.

The idea with translations is great btw.
 
Last edited by a moderator:
Neither of these comments have anything to do with the topic of this thread.

Why not? The decision whether to adopt, or "approve" a proposal like this might as well lie with the Masternodes. And it addresses exactly the point of a general solution about what the community is willing to agree on. Even if there is no template whatsoever, why should we not seek to find out if we can establish a consensus about something that could apply to most or all projects?
 
I think the key issue here is that the budget system is not owned by anyone.

With a suggestion like this it would in some way be bringing the budget system under the control of the Dash Foundation (their support would be needed to gain masternode support). In my opinion the budget system should remain completely open to proposals of all kinds, and that establishing a gate keeper of sorts would be a bad idea.

Remember that the system is designed so that the core team could be unfunded and replaced if the masternode operators deem them to be under performing or operating against the best interests of Dash.
 
Why would this increase control by the DASH foundation? It would just be Masternodes exercising control over themselves.
 
  • Like
Reactions: kot
Please also do not use the word "corporate" (in all forms) as a synonym for something bad and useless.

These are not only bad and useless; these are private tyrannies that do not give a flying f*** about humans, human rights, or humanity as a whole as they callously pillage whatever they can and are best described with this cartoon:

 
Back
Top