What's your project management methodology or general process tips?

Visibility is important. Management is made a little easier when you have real time capability to easily reveal and drill into activities, costs, budgets, etc.

You're not alone as many make it up as they go. The Project Management Institute (PMI) commonly has developed the PMBOK (Project Management Body of Knowledge), which is a useful set of tools. These can become unwieldy if someone tries to apply them to every "project."

Three elements I find important to understand manage universally (in priority order) are (a) communications, (b) sponsorship, and (c) constraints (specifically, the tradeoffs between cost, scope/quality and schedule). Most PM practices build on this foundation.

In general, I'm a proponent of "Agile" or "Lean" methods and there are are a suitable choices for about any circumstance. If an organization is looking to improve (or begin to implement) general PM practices, I would first look to Agile/Lean and understand the concept of MVP (minimum viable product) and THEN selectively overlay useful practices from the PMBOK.

There are some good, short Youtubes on MVP. Really understanding how these concepts apply to your business will jumpstart the process.

John offers some great advice. As you can guess, there's no one size fits all for PM. I really like FranklinCovey's Project Management model because it captures the usually overlooked reality that projects involve people, so you really have 2 things to manage: the people and the project. Obviously, both are not managed the same. I have also found that the model is simple enough that the framework can be used most every time...even loosely for smaller ones. I try not to engage projects without at least a loosely defined project plan.

For the people involved, they suggest: 1) Demonstrate Respect, 2) Listen First, 3) Clarify Expectations, and 4) Practice Accountability.

For managing the project, they categorize 4 key processes that must be managed...carefully: 1) Initiating Process (Visualizing), 2) Planning Process (assuming the project is a 'go'), 3) Executing and Controlling Process (after reviewing the Project Plan and reaffirming it is a 'go'), and 4) Closing and Evaluation.

There's obviously a lot that goes into each stage, but the nice thing is that you can go as deep or shallow as the project warrants. I don't believe they've published this content in a book, but you can easily find relevant content (again, John made some great suggestions). I hope this helps.

The key for us has been communication. Scheduled update meetings with the business owner and sponsor of the project. Quickly pushing up the ladder issues that are derailing progress. It is important to have some way to classify projects and not let red tape and formalized reporting slow things down when the scope does not warrant that type of control. On the flip side, it is important when small issues can create major problems on a given project. We do push to have the business partner outline, in some detail, what the objective is on a project before we get too many folks engaged and we make sure management is aware we are devoting resources in case they feel things should be prioritized differently. Finally, we make sure we have the resources to meet expectations.

I agree with Mark. First and foremost is Communication, whether it is with sponsors, team, end-users, vendors, or customers.

-> One crucial factor in the communication process is managing Expectations.

-> Right alongside managing expectations is team alignment. Everyone must be on the same page. That coincides with, and dovetails into Mark's comment.

All the other aspects are off-shoots of these two issues.

-> Timelines change; unforeseen circumstances happen, mission scope diverges or digresses.

All can be overcome if and only if the issues are communicated with all the interested parties.

I learned a long time ago that winging a project is a big mistake. But, like most people, I still do it from time to time for smaller projects.

I have found that most problems with communications, expectations, and establishing criteria is the uncertainty that many people have about what they want done. They have a vague idea about what they need but are unable to articulate it. Unless this situation is curtailed at the beginning you are going to experience a lot of project creep. I found that the project manager needs to discuss what is needed with the principle users and their managers and then get the lead user and his/her manager to sign off on a summary of what they say they need. That way, any changes can be incorporated into a new project as the current one sails on toward completion without a bunch of side trips to add additional features that came up as their vague ideas begins to crystallize.

Even when winging a smaller project, I try to always include this step in my project planning . . . it keeps the small project from becoming a long-term BIG problem one.

Having recently been subjected to the most onerous attempts at project management, I'd like to weigh in on this conversation. While it is important to have a system, to keep track of things, to have check lists to make sure everything is covered and to remember critical paths - these are not the project.

That seems to come as a surprise to many overly-detailed folk who forget about the most important elements: The project itself - in other words the content and the people involved.

When the details get in the way of the work priorities are askew. When timelines become more important than working positively with people, you might meet the deadlines but the quality of work will suffer and resentment often brings with it passive-aggressive and/or sabotaging behaviors

So, let's keep our priorities straight - it isn't about checking off boxes. It isn't about using the latest greatest software. It's about encouraging and motivating the people to do a fabulous job on the project.