How to handle project that (I think) not using any framework or has unclear workflow?

Question

Let me describe what's in the project, The people involved in this project is:

• Company owner
• Project owner
• Consultant
• 4 software engineers

---

I'm one of the software engineers there. The responsibility/what they do are:

Company owner

• Most of the requirement is defined by them and transferred to the Owner of the project (I assume this is done orally, there's really no documentation about this)

Project owner

• Brief the software engineers about the requirement from the company owner by telling it in the meeting.
• Verify the progress by watching the application runs demonstrated by the engineers and sometimes by handing the app to the future user of the app.
• Listen to the Company owner/user feedback and translate it to a new requirement that soon briefed to the engineer.
• Discuss with the consultant/engineer what is the best practice when dealing with a problem/requirement.

The project owner has other many responsibilities, so the availability is somewhat limited.

Consultant

• Get asked opinion from the project owner about what is the best practice from a problem/requirement.
• Tell/influence the project owner if some requirement is just too difficult to manage later.

The consultant just appear once in a while, so doesn't always available to engineer onsite (maybe available to the project/company owner)

Software Engineers

• Develop the project
• Writing/take notes about the briefed requirement
• Demonstrate/report the project progress.

Note: this is from my point of view. there's no handbook about this

---

Project Management Tools

• Notepad/ Text Editor
• Trello
• Slack

The problem

The project owner admits that the requirement isn't all clear, it needs to be discussed with the company owner and all the potential user. So often the requirement changes.

The requirement isn't documented by a framework so it is just a text from a full meeting. The meeting text isn't always verified by the project owner. The text is just a brief description of a new feature and the constraint, not really detailed like a flow diagram, sequence, etc.

I think the project owner just assume what he thought about was already stated in the meeting and the engineers wrote all the correct description about it and will implement as is.

After a meeting passed, the text will be posted to slack and break down by the engineer to the trello board. The project owner and the consultant can read the slack and the trello board. But there wasn't any complain/correction made to those document. I have a feeling, there may be an occasion where it's not correctly written. But seems it just got away every time.

The structure of the trello card isn't defined either. Sometimes it titled by the module engineers worked with and contains checklists of the break-downed task from the meeting (not really detailed) [1]. Sometimes it is just a single task with a little bit detailed description [2]. Maybe that's why there's no complain/correction, but I already talked about it. The project owner & consultant seems just agree and let the engineer take care of it.

And in my opinion, the review process from the project owner seems doesn't complete. It just jumped from one to another feature. When it seems partially complete the project owner already jumped to review another feature. And sometimes just adding more requirement to be done. When I asked my teammate, they feel that although we finished developing a feature, it doesn't feel complete.

---

I want to propose better project management for this situation, but I haven't really had the experience to say. What kind of project management can be put into work there? I read somewhere that agile is good for prone to change requirement. Should I say agile?

But really, I haven't had any experience about it. I'm afraid, by just doing what I partially understand results in more hassle than good. I want all of the party satisfied by working on this project.

I already talked about this problem with the project owner and all the engineers. We agreed that we'll discuss this in the upcoming meeting.

Answer 1

This might be too broad of a question to answer completely in a post like this. I'll encourage you to think about your situation and break it down into sub-problems.

It sounds like there are at least two.

Problems

First, at least some stakeholders (you) are uncomfortable with the current way the project is being run. This can be due to the lack of framework -- there isn't a clear process on features are identified, elaborated, documented, and implemented. There isn't clear responsibility for who owns this requirements definition process either.

Second, there is a lack of communication of what the requirements are. This is related to the first, but they can be addressed separately.

My recommendations

To address the first, encourage discussion of the problem among your team. What processes are necessary to ensure that the project is being delivered in an effective way? Are there any frameworks that will help you to achieve this? Slack and Trello boards can be a good start, but you'll probably need additional structure. Look into Scrum as a simple way of running projects of this type.

To address the second, and this is more important in my opinion, there needs to be strong two-way communication between the people who implement the features (you and your dev team) and the people who ideate them (business owner, project owner, users, and consultant). I suggest meeting with them every week or two to identify the most important requirements, develop them in detail, and prioritize what will be delivered. This is more or less in line with Scrum's "sprint planning sessions."

You are not in a unique position. This is a fairly common scenario. Communicate, try new things, and always seek to improve your process. This experience will be helpful as you progress in your career.