After Hours

10 questions non-techie managers should ask about IT projects

Business managers may lack the tech knowledge to make sure a project is on the right track. Here's what they should be asking IT to improve the odds of project success.

If you are a non-techie responsible for a project that involves developing or enhancing software, it can be hard to ask the right questions. It is critical, though, to stay engaged in the software development process and to keep the communication flowing -- this greatly improves the likelihood of a successful project. Below are 10 questions that non-technical project stakeholders should ask their techie counterparts.

1: What's the best way to communicate with the technical resources?

This is a question you can ask an IT manager. Maybe there is a business analyst or project manager from IT assigned to coordinate and communicate with your techies. But if there isn't, that task may fall to you. Some techies will be much better at understanding your "business needs" than others. Make sure that the requirements are written down and that you read them (even if they are boring!). After you read them, go over them with your BA, PM, or techie. Even just paraphrasing each requirement can help avoid costly communication failures.

2: Can you show me what you've got so far? (Ask repeatedly)

The sooner you can provide feedback to your IT counterparts, the less costly it will be to make important course corrections. Let's face it: It's difficult to conceptualize how something like a piece of software will work based on written requirements. It's only when you see it in action that you find all the things that weren't mentioned or were, worse yet, just assumed. Ask to see the latest work -- even if it is incomplete -- so you can provide feedback. Maybe you will be providing feedback on a login page or a search screen that doesn't do anything yet. It doesn't matter. Get the team used to regularly showing you progress. Also, it never hurts if you've got donuts or bagels when you come around.

3: Are you waiting on me for anything?

Some projects will have a full-time project manager who will be keeping careful track of open issues. If you don't have a resource supporting you like that, make sure you track open questions and issues carefully. It's always a good idea to ask the techies if they're still waiting for an answer from you on something you missed.

4: How will this be tested?

A well-managed software development team will create a test strategy near the start of the project. Understand what that strategy is and ask questions if it doesn't make sense to you.

5: When can I help with testing?

Make sure that you or your users play an integral role in testing. That role may be to help develop test cases or it may be to test, hands-on. Ideally, it is both. Be sure that representatives from the business side are playing an active role in testing. They will have a better intuitive understanding of what is "right" than full-time QA folks who need to rely on test-scripts.

6: How does this system or change affect our other systems?

In a company with lots of systems that interact with each other, it can be difficult -- for business users and techies alike -- to identify how a change will affect other systems. As a business stakeholder, you should dedicate some time to thinking through how the project affects other downstream processes. You should also have a focused discussion with your technical counterparts on where the new or modified system touches other systems. If your project affects other systems, make sure they're considered in the test strategy you asked about two questions ago.

7: What does the system do when something goes wrong?

Unfortunately, things will go wrong. All well-designed systems should be designed to handle errors as gracefully as possible. Ask this question to verify that your system is being designed this way. Answers like "I don't know" or "They will get some kind of exception message" aren't good. Good answers will include an explanation of how the user and support staff will be notified in a way that makes sense; how bad or incomplete data will be prevented from going into the system; and how the process can be restarted after the error.

8: Can you show me the audit trail?

Most business users assume that all computer systems keep great records of what everyone has done on the system and all the history of changes and transactions. In general, none of this happens unless the people who developed the system thought to add those features. If these features are important to you (and I have seldom seen a business system where audit trails weren't important), make sure that they are part of the requirements and ask for a demonstration.

9: What happens when you are done?

Many projects risk falling apart during the handoff from the technologists to the business. Make sure there is a clear plan for what happens when the programming and testing are done. You may be focusing on a training plan or customer communication strategy, but you need to make sure the technical team has a solid plan for moving the system into production and transitioning from development to operations. This should include establishing who supports the system going forward as well as mundane issues, such as making sure backups are in place. Also, you know there are going to be some changes needed after the first release. Make sure the technical resources are available for those inevitable adjustments.

10: What do you think?

There are plenty of techies who aren't afraid to speak their mind about any number of subjects (regardless of whether they have an informed opinion). However, there are also plenty who really understand what the business is trying to achieve but are reticent about expressing their ideas. Ask them their opinions -- you may gain some valuable insights.

Good technologists -- such as the ones on my team -- will bring up these questions themselves. But it never hurts to make sure. Take the time to ask these questions and any others you can think of. Use the project as an opportunity to expand your horizons a little and learn about how these systems work and are built. More than anything else, stay engaged in the project from start to finish. This will help ensure that you can ask the 11th question: "Where should we celebrate the successful completion of the project?"

Additional resources

About

Keith is the Director of Applications at Little Caesars Enterprises in Detroit. Prior to that, he was the CIO of a health services company. His 20 years of professional experience have included positions as an executive, a consultant, and as the fou...

12 comments
bimhau
bimhau

It???s also worth considering, and also prudent, though not always popular, to ask the current team(s) to help plan the demigration of this ???new thing.??? In five to ten years, someone else is going to have to handle that task, and the understanding of this ???new thing??? may be thin or hard to find at that time. If you can engage the current skillset to help plan the ???sun setting??? of this ???new thing???, it helps the next team and encourages a business success. You can also help this ???new thing??? have a good reputation at sun setting time, because it will be more favorably acknowledged by the next team. Think about what resources your current team would have appreciated from the team prior to them.

csudholz
csudholz

Nice article. I agree. I always ask IT developers the question "show me the evidence that ....", it works, people want this, data is well managed etc, etc. Such a simple question always exposes the issues.

zrojasr
zrojasr

These are questions that naturally occur when a healthy relationship has developed between IT and the business community. And like all relationships it takes the right people in an open environment willing to build trust and maintain an honest dialogue.

kfaigin
kfaigin

Lehnerus2000 has it right --- I am using the language of business, or at least trying to. I've been a technical resource for most of my life and don't have any problem with that terminology. Still, it may make sense to start drafting "Ten Things that Technical Resources Have in Common with People" for use by business managers.

blarman
blarman

Even for non-technical managers, #10 is important. Your best ideas will always come from the people closest to the source of the problem because they have to deal with it every day. Your business will improve much faster if you listen to them and it is a great way to build rapport.

lehnerus2000
lehnerus2000

He's writing in "business-ese", so that business managers can understand him. ;)

Tocsin
Tocsin

Come on - "technical resources" - how about calling us "people" ?

kfaigin
kfaigin

I think the way you are thinking really separates your attitude from the often-heard approach of "I certainly won't be around in X years when this stops working".

kfaigin
kfaigin

'Show me the evidence'... great mantra for getting to the truth behind the curtain.

PMPsicle
PMPsicle

A QA person doing testing????? Sorry that's a QC function. QC = Quality Control = Testing QA = Quality Design of Processes = Business Process Management = Identify where you need to test & what you need to do to ensure quality is built in.

Editor's Picks