How to suggest project improvements in a rigid / narrow-minded environment?

Question

Briefing:

I'm a new employee at a small company that has a lot of talent but seems to have gotten by with ad-hoc processes simply because they've had mostly small projects and repeat customers who are friends with the company executives.

Some background:

I recently started a new job at a 20-person custom (per contract) software company. The first project I was assigned to is still in progress and is not going well (I asked this question before registering here). I don't know if I was unlucky and started on the 1 in a 100 project that is poorly managed. What I'm afraid of is that stumbling around with unclear requirements, unrealistic expectations and no toll gates put in place for hard customer-provided dependencies is standard.

And I don't care what the norm is. All I really want is to make sure that the I don't end up on a project like this in the future and the only thing I can think of is to help my company implement the tools and processes to accomplish that.

So, we just kicked off our biggest project in the history of the company. It's 4 times as big in terms of cost than our largest previous project. We just had a call this morning where the president said that everyone in the company would be involved in the project in some fashion (compared to the standard 1-2 devs and a part time PM per project).

This seems like a perfect opportunity to help my company out. I've got some ideas but like I mentioned, no PM experience. I have no desire to get PM experience either but I'll do what it takes to improve my company.

Here's what I've come up with so far:

1. Implement source control - currently no project or developer uses SC except myself. I have a a SC server running on my personal dev box that I use to track changes, create branches for testing new functionality etc.

2. Put up a wiki - A few weeks ago I found out that another developer had spent a day trying to get a particular technology working that I had just got up and running myself. He would have saved a few hours at a minimum if he could have gone to a central knowledgebase where I could have recorded my experience.

3. Use some sort of PM tool - The CEO just signed up for a Basecamp account. I use it to keep track of todo lists (translated from the functional requirements excel spreadsheet). No one else in the company except the PM on my project uses it.

4. Implement a bug tracker - The bug tracker for my current project is a text file on the server that feedback requests get logged to. That and long email chains from our client that often start with "Such and such doesn't work for me".

5. Be a crusader - I've tried preaching the benefits of all these tools and techniques but have been met with an attitude of "Don't spend too much time on it. Just work on coding".

As you can see most of my ideas involve some sort of new tool or technology (new to my company anyways). How can I point out flaws in my company's processes without seeming like a know-it-all? I've only been here for a few months and just want my projects, team and company to be incredible. I love what I am doing at my new job. I just don't love how we do it.

Answer 1

You are definitely in a tough position, and I applaud you on trying to make things better for your group. One thing I'd suggest is that you not try to tackle everything at once. Look at the specific problems you face, decide on which ones to tackle first (maybe based on how easy it is to convince the rest of the team, maybe based on which ones you can get statistics for). Once you have some successes, it will help make your case for future changes.

You don't mention whether your team is at a single location or distributed. Most of my suggestions below are targeted towards co-located groups, but you can adapt many of them for distributed teams.

Here are some suggestions (not in any particular order):

• Make sure to talk to the rest of the team in one-on-one situations. Perhaps other people are seeing the same issues or having the same pain. Try to gain a bigger picture of everything.

• Don't be afraid to improve your own practices, even if the team isn't going to follow one of your suggestions. Consider implementing it for your own piece of the work, unless you are told not to. Definitely talk about it with the PM though (don't just do it on the sly). It sounds like you are already doing this with source control, but don't be afraid to implement other things as well.

• Speaking of other tools/practices to consider:

  • design reviews (even informal over-the-shoulder reviews are better than nothing)
  • code reviews
  • automated unit testing
  • automated build server

• Adapt a practice of developing small units of functionality at a time. Make sure you can check in working code on a daily basis (give or take). Make sure that you are always moving forward, even if it is just a small step. Talk with the PM about applying this across the team as well.

• Once you've gotten to the point where the code is "always" in a working state, suggest to your PM that your team adapt a regular schedule for meeting with the client to show progress.

  • These reviews can help ensure that your team is building the right solution. It is much better to find out that a week or two of time has been on the wrong path, than to find out that 6 months have gone the wrong direction.
  • The client will likely be more comfortable with your status as they will have visually seen where you are at
  • These meetings can be a great time to discuss priorities (what to tackle next) as well as any issues that have arised or risks that are likely to materialize in the future

• Visual reminders and process controls.

  • Does everyone on the team know what the core goals of the project are? I don't mean "get this product done by date X", but more like "make sure that users rate our product 4 stars or better". Make sure the team understands these goals, and put them up in the project area. Or just up on your cube/office wall if there isn't a team area.
  • Does everyone on the team have the same view of the development process? Consider implementing a work item tracking board that shows your team's development process. While I'd probably suggest a kanban board (and the process that helps drive), this could simply be a reflection of where things are currently and what things are coming up. While an electronic version of this is better than nothing, having it visible to the whole team on a big whiteboard seems to have more of an impact in my experience
    • once you've got this in place, start having short (15 minute or less) daily meetings with others on the team in front of the board. Focus the talk on areas that people need help with, or problems that they see coming up.
    • if the team isn't up for it or if there isn't an area for a team version of this, at least consider putting one up for things that have been assigned to you, and spend a few minutes each day reviewing it

• additional team communications methods - Some of these serve overlapping purposes, you can mix & match to fit your team

  • wiki
    • you've got this
    • make sure to encourage others to add to it
    • if you receive info that is useful to the team (think email traffic that says how to do something), start copying it to the wiki
  • email distribution list
    • good for sending out info that the whole team needs
    • needs someone responsible for getting new team members added in a timely fashion
    • if information is important to save for later, someone needs to get it into the wiki
  • internal chat server
    • great way to fire off quick questions without worrying about sensitive info going outside the company
    • as above, someone may need to copy the info to the wiki
  • Q&A server
    • basically, an internal version of Stack Exchange
    • answers might wind up referencing the wiki
    • answers might need to get copied to wiki

• Start a book club - focus on books that apply to problems your team actually sees. Hopefully, the people that have been at your company longer will wind up talking about how they can see the book applying to what they've experienced in the past, which gets them thinking about it more as well as giving you more insight into the situation. Off the top of my head, some suggestions for book topics would include:

  • implementing change within companies (Fearless Change)
  • agile and lean methodologies (too many to name)
  • development practices (Pragmatic Programmer, Code Complete, The Developer's Code).

Answer 2

These are all excellent ideas. What you need to be careful about is how you present them. Not, for example,

I can't believe you IDIOTS aren't doing source control!

(I'm exaggerating for effect here)

but rather:

I've read about some organizations that have implemented source control, and they've really been able to save time and money ...

(Talking about time and money will cause your boss' ears to perk up.)

Good luck!

Answer 3

You need metrics above anything else for this crusade, and you need to choose your battles wisely. There's no method or tool that can hold strong against misuse, so your suggested improvements are easy to "prove wrong" by people involved but not 100% on-board. So go for some easy wins to win trust from management, and most importantly, the team-members.

Start with something small, that is easy to make reliable before/after measurements on. Make a plan for improving this area, and stick to your guns; don't accept a "kinda woulda shoulda" version of your plan. By keeping your first improvement small and cheap, this should be easier to swallow for everybody.

If you succeed in making a measurable improvement, you'll create an opportunity for everybody else to believe that change is possible, and you will see suggestions pouring in from all corners. You aren't the only one in the company who knows that things could be better - but you're probably the only one who believes it's possible. This is the most important change your proactive attitude can instigate :)

Answer 4

You are ambitious, that's good - I'm just like that. I have worked in a start-up software house, then I kept moving through larger organizations over the period of time.

Each time I wanted to make a change by automating a process. Eventually I came to realise that the majority of small companies that are not working on enterprise solutions will be mainly concerned with the time to market (making money). They might not exist in the next year or six months, so they generally think that better quality and automation is a luxury that they want, but can't afford.

You will need to justify the spending to your management, and I found that it isn't easy to do. They will generally agree with you, and say it's good, but it can wait until it's really needed.

I'm now working for a successful software house (still relatively small company) where everything is driven by automating processes (Continuous Integration). It's now part of our culture but it took us a while to get here.

Now, regarding the tools that you have mentioned - yes, I think that they are good and you can generally get them up and running within few days. But this is only a tip of an iceberg, maybe it makes sense to find a working environment with a different culture?

Edit:

My answer is based on what I have previously experienced. I've suggested to change a working environment because I have previously tried to automate processes in smaller companies, but I have failed because all they were concerned with was time to market. All they wanted to do was to get the system out of the door and not worry about what might happen in the following six months.

Regarding current company I work for, a technical director knows how the software engineering company is supposed to function. He has hired the right people, broke us down into departments (front-end, back-end, db, server side, testers, "process maturity", quality assurance leads etc). Our processes are driven by continuous integration and I can get into details of what we have achieved/failed to achieve. We are quite good, but our Capability Maturity Model (http://en.wikipedia.org/wiki/Capability_Maturity_Model) is still somewhere between two and three, it's good, but there is a very long way to go. In your organization, it sounds like it'll take quite an effort to move from level one to level two. Hence why I have asked you whether you've considered changing a working environment.

Answer 5

Believe it or not, most organizations, whether it is about PM capabilities or other business capabilities, are low on the maturity scale. Gartner estimates something like 70% to 80% of organizations are either level 1 or 2 of a 5-point scale for BPM. Before you implement any change, or even before you propose change, stand up a competency / governing body, a group of like minded resources that will include those with rank, to begin problem identification, opportunity identification, research, training, building a case for change, etc. This group may evolve into a PMO-like organization or may dissolve down the line, but it is nearly essential to get the ball rolling. We have found in our BPM consulting that this is almost law.

So, your ideas notwithstanding, take a step back and look into the idea of this PM competency group.

Answer 6

It can be counter-productive to enter into this with the perspective that the organization you are trying to change is "rigid" or "narrow-minded." Those terms carry negative connotations which can undermine any positive changes you are trying to make.

I would recommend taking a step back and looking at all the things the company does right. For example, they seem to be making enough customers happy that they can grow, hire people and pay their salaries (not to mention rent and other expenses).

Understanding what they do right will help improve the delivery of these changes and will provide a deeper understanding of how to make the changes and which changes will have the most chance of success. It will also help you grow the number of people interested in making change since there are likely a lot more people who want to help the company than there are people who want to "rebel."

Not to sound to zen about it, but there is no one-size-fits-all set of recommendations. The kind of improvements you are looking to make come from trust relationships and a respectful understanding of the current company.

Answer 7

I am impressed by your desire to go out of your way to help your company. I have some ideas for how you can start in small ways, so as not to be pushy. I think the biggest issue lies in the lack of business process used in your company. I suggest focusing on this before looking to improve issues in programming, because you are surrounded by programming experts who are capable of making these changes themselves. Instead, implementing standardized processes will keep the team organized and focused. Here's some ways you can start building these processes without being upfront about it:

• Take advantage of those PM tools. Basecamp is great for to-dos. If you are looking for better communication, consider apps like Slack for messaging. If you want to automate your workflows to improve process management, consider Tallyfy. Invite your coworkers to these apps, it won't take longer than a few minutes for them to realize what they are missing out on.
• There's no need to preach to your coworkers. Try approaching the manager and showing them how efficient you have become by using these apps or sketching out business process. Hopefully he or she will appreciate your passion for the growth of the business. If that doesn't work however, continue to use these tools around coworkers, without blatantly trying to sell them anything.

Even if only a few people follow in your footsteps, in a team of only 20 you can make an impact. Hopefully from there your business process management tools will spread company-wide once the narrow-minded start seeing results.